Komentarze w języku JavaScript to zagrożenie bezpieczeństwa?

Question

Podczas badania recient PCI biegły stwierdził, że mieliśmy poważne zagrożenia dla bezpieczeństwa, ponieważ

1. można było pobrać zasoby statyczne z naszej strony takie jak obrazy CSS i JavaScript bez uprzedniej autoryzacji.
2. Nasz javascript zawierał komentarze.

Osobiście uważam, że nie stanowi to zagrożenia dla bezpieczeństwa. Obrazy css i javascript nie zostały utworzone dynamicznie i nie zawierały danych na temat naszego zaplecza, szczegółów naszych klientów i mechanizmów.

Komentarze w javascript po prostu wyjaśniały, co zrobiły metody w pliku javascript. Którykolwiek, kto czyta JS, mógł i tak się dowiedzieć.

Jak to pokazuje "information leakage"?

Czy komentarze w javascript naprawdę stanowią zagrożenie dla bezpieczeństwa?

Answer 1

W zależności od rygorystyczności audytu, pobieranie obrazów itp. Bez uwierzytelnienia może być postrzegane jako zagrożenie bezpieczeństwa (pomyśl schematów, wykresów, wykresów ...).

Usuwanie komentarzy w javascriptu jest jak zaciemnianie kodu: czyni to nieco trudniejszym, ale nadal nie jest niemożliwe zrozumienie, co się dzieje. JavaScript powinien być postrzegany jako usprawniający - w każdym razie wszystkie twoje zabezpieczenia powinny być (duplikowane) po stronie serwera. Posiadanie kogoś, kto rozumie, co robi JS, nie powinno być uważane za ryzyko.

Answer 2

Nie wdając się w ryzyko związane z bezpieczeństwem, zminimalizuj swój system JS w środowisku produkcyjnym, zapobiegnie to "wyciekowi informacji" i pomoże (przynajmniej w pewien sposób) zabezpieczyć informacje dotyczące twojej witryny.

w związku z zagrożeniem bezpieczeństwa, nie uważam, że komentarze JS są w ogóle ryzykiem, każda treść strony (statyczna) może zostać pobrana bez uwierzytelnienia. (o ile nie określono inaczej)

Answer 3

Nie, jeśli ujawniają tylko sposób działania kodu. Jakakolwiek wystarczająco zdeterminowana osoba mogłaby to stwierdzić.

To powiedziawszy, prawdopodobnie dobrym pomysłem jest zminimalizowanie kodu JavaScript; nie ze względu na bezpieczeństwo, ale dlatego, że skróci to czas pobierania, a przez to sprawi, że Twoja witryna będzie bardziej responsywna.

Answer 4

Komentarze JavaScript mogą być. zależy od twojej logiki, ale z pewnością, ponieważ jest publicznie dostępna, dajesz większą widoczność działaniom twojego kodu.

Istnieją również inne powody, dla których warto je usunąć, takie jak rozmiar pliku i rozmiar pobieranego pliku.

Narzędzia, takie jak JSMin, mogą pomóc w usunięciu komentarzy i perfromie z prymitywnym zaciemnianiem kodu.

Answer 5

To zależy od treści komentarza. Ponieważ nie ma możliwości, bez interwencji człowieka, przeanalizowanie treści komentarzy w celu ustalenia, czy są one ryzykowne, najskuteczniejszym sposobem kontroli jest zadeklarowanie wszystkich komentarzy w kodzie źródłowym skierowanym do klienta jako ryzykowne.

Oto przykłady potencjalnie ryzykownych komentarzy.

// doesn't really authenticate, placeholder for when we implement it. 
myServer.authenticate(user,pass); 

lub

// don't forget to include the length, 
//the server complains if it gets NaN or undefined. 
function send_stuff(stuff, length) { 
... 
} 

lub

function doSomething() { 
    querystring = "" 
    //querystring = "?TRACING_MODE=true&" 
    ... 
    //print_server_trace(); 
} 

Innym przykładem może być, jeśli obejmują historię nagłówek kodu źródłowego, ktoś może być w stanie znaleźć jakąś słabość zabezpieczeń badając rodzaje Błędy, które zostały naprawione. Przynajmniej krakers może być w stanie lepiej ukierunkować swoje ataki, jeśli wie, które wektory ataku zostały już zamknięte.

Wszystkie te przykłady są jednak i tak złymi praktykami (zarówno komentarzem, jak i kodem), a najlepszym sposobem, aby temu zapobiec, są przeglądy kodu i dobrzy programiści. Pierwszy przykład jest szczególnie zły, ale niewinne ostrzeżenia dla kolegów z drużyny, podobnie jak drugi przykład, lub skomentowany kod debugowania, jak trzeci, to rodzaje luk w zabezpieczeniach, które mogą prześlizgnąć się przez sieć.