Skrypt w folderze to usterka?

Question

W moich aplikacjach internetowych .NET zwykle mam folder Skrypty, który zawiera wszystkie moje pliki JavaScript - obecnie jQuery, z okazjonalną biblioteką JavaScript jakiejś lub innej.

Używam skanowań luk w zabezpieczeniach na jednej z moich stron internetowych za pomocą skanera o nazwie Nexpose i poinformowano mnie, że folder Skrypty jest otwarty na świat - co oznacza, że ​​nieuwierzytelnieni użytkownicy mogą pobrać pliki JavaScript zawarte w folderze i że jest krytyczną luką. Według Nexpose folder Skrypty powinien być ograniczony do zezwalania tylko na uwierzytelnionych użytkowników. Co prowadzi mnie do mojego pierwszego pytania.

Jak ograniczyć folder Skrypty tylko do uwierzytelnionych użytkowników? Próbowałem umieścić plik web.config w folderze Skrypty i odmawiając dostępu do wszystkich nieuwierzytelnionych użytkowników w ten sposób, ale to nie zadziałało. Sam mogłem to ustalić, ale przechodziłem na stronę logowania mojej witryny, ale nie logowałem się, a następnie wpisując https://mywebsite/scripts/menubar.js i na tyle, że pozwoliło mi to pobrać plik menubar.js.

Drugie pytanie - Dlaczego jest to usterka? Próbowałem zrozumieć moje możliwości, ale nie udało mi się w ogóle wymyślić. Czy jest to usterka, ponieważ Joe l33t h4x0r mógł wykryć różne biblioteki, z których korzystam, a następnie może wykorzystać znane exploity przeciwko nim?

Aktualizacja

przeważającej mierze odpowiedź wydaje się być to, że w żaden sposób nie powinny luka istnieje tylko dlatego, że js plik można otworzyć i przeczytać w przeglądarce klienta. Jedyną możliwą luką może być sytuacja, gdy programista używał pliku .js w pewien niepewny sposób (którego nie jestem).

Answer 1

Logicznie rzecz biorąc, nie chciałbyś w rzeczywistości uniemożliwić dostępu do rzeczywistych plików, ponieważ wtedy nie możesz ich użyć na swojej stronie internetowej. Serwer internetowy nie rozróżnia przeglądarki żądającej pliku jako części procesu renderowania strony internetowej w stosunku do kogoś, kto po prostu ręcznie pobiera plik.

W rezultacie odpowiedź na pierwsze pytanie brzmi: nie możesz i nie chcesz. Jeśli nie chcesz, aby użytkownicy mieli dostęp, wyślij go z folderu sieciowego. Jeśli musisz renderować witrynę, musisz , aby każdy miał dostęp do niej, aby Twoja strona mogła być wyświetlana prawidłowo.

Co to jest za słabe narzędzie, kto to mówi? Mogę teraz użyć dowolnego JavaScriptu Facebooka. Albo, co ważniejsze, mogę przejść do strony Bank of America lub Chase i zacząć przeglądać ich JavaScript. Gdybym miał konto, mogłabym nawet rzucić okiem na JavaScript używany po zalogowaniu użytkownika.

Jedyne, o co musisz się martwić, to to samo, o co musisz się zawsze martwić: ujawnianie szczegółów które nie powinny być narażone. Nie jestem pewien, dlaczego tak, ale oczywiście nie byłoby dobrym pomysłem umieszczenie hasła do bazy danych w pliku JavaScript, na przykład. Poza tym, nie ma się czym martwić.

Answer 2

Tak. Powinieneś zachować większość przetwarzania po stronie serwera, ponieważ większość (jeśli nie wszystkie) skrypty po stronie klienta mogą być edytowane i takie. Większość witryn korzysta z Javascript, więc po prostu używanie go nie jest niebezpieczne, po prostu musisz uważać na to, co z nim robisz.

Ponadto, aby odpowiedzieć na pierwsze pytanie, nie należy ich chronić, jeśli nieuwierzytelnieni użytkownicy tego potrzebują.

Answer 3

Wygląda na to, że niektóre zestawy zabezpieczeń mają swędzący palec spustowy. Jedyne dwa problemy, jakie mogłem zauważyć, to to, że mógłbyś w końcu wypożyczyć swój serwer jako CDN, jeśli ktoś zdecyduje się wskazać na twoją jQuery lub twoją -instrukcję biblioteki tutaj- LUB (teraz to jest prawdziwe zagrożenie bezpieczeństwa) jeśli udostępniasz także dowolne dynamiczne pliki .js, które mogą stanowić potencjalne zagrożenie. Jedyną rzeczą, o której mogę pomyśleć jest to, że masz "niestandardową" aplikację js w połączeniu ze wszystkimi bibliotekami, w których ktoś mógłby potencjalnie wykryć punkty końcowe (usługi sieciowe i inne) i spróbować sprawdzić, czy są bezpieczne ... ale to jest to! nic więcej ... (chyba, że ​​zrobiłeś coś naprawdę głupiego jak twardy kod hasło lub coś tam ... lol)

Answer 4

Tak więc atak nie polega na tym, że ludzie mogą edytować skrypt atakuje serwer internetowy arbitralnie zapisywać do katalogu. Musisz upewnić się, że są to pliki tylko do odczytu. chmod 400 lub windows odczytać. Jeśli chodzi o Defence in Depth (DiD), chcesz mieć pewność, że serwer WWW nie jest uprzywilejowanym użytkownikiem, który nie może zalogować się do systemu. Ponadto konieczne jest, aby wszystkie dane zostały oczyszczone na serwerze, niezależnie od tego, co robisz po stronie klienta, ponieważ nie kontrolujesz strony klienta. Zazwyczaj wiąże się to z koniecznością oczyszczenia wszystkich danych pochodzących z sieci, a także bazy danych przed jej udostępnieniem.Jedną z moich ulubionych rzeczy jest wstawienie dowolnego javascript do bazy danych i obserwowanie, jak robi on rzeczy w interfejsie, ponieważ zespół programistów zakładał, że wszystko będzie dobrze, ponieważ już raz je wyczyścili.

Mogę podać więcej szczegółów dotyczących zabezpieczenia systemu, jeśli jest to uzasadnione.

Answer 5

W większości przypadków nie jest to usterka. Rozważ wszystkie masowe witryny publiczne z anonimowym ruchem i/lub gdzie bardzo łatwo stać się uwierzytelnionym użytkownikiem (Google, eBay, Amazon itp.). Strony te zawierają również najbardziej rozbudowane skrypty.

Im bardziej subtelną rzeczą, na którą należy zwrócić uwagę, są inne pliki, które CHCESZ chcieć chronić. Na przykład, jeśli użytkownicy muszą zalogować się do witryny i kupić dokument, wideo, obraz itp. Przed jego wyświetleniem, z pewnością nie powinien on znajdować się w publicznie dostępnym folderze.