Sjoerd

2019-02-04 19:38:54 UTC

view on stackexchange narkive permalink

Walidację danych wejściowych należy wdrożyć jako metodę kompleksowej obrony. Dlatego sprawdzanie poprawności danych wejściowych nie powinno być podstawową obroną przed wstrzyknięciem SQL, które powinny być przygotowanymi instrukcjami. W ramach dodatkowej obrony powinieneś ograniczyć dozwolone wejścia.

To nigdy nie powinno ograniczać funkcjonalności. Jeśli istnieje uzasadniony przypadek użycia, w którym wprowadzane są apostrofy, należy na to zezwolić. Dlatego powinieneś zezwolić na pojedyncze cudzysłowy w polach nazw, opisach, hasłach, ale nie w polach liczbowych, polach nazw użytkowników i tablicach rejestracyjnych.

Blokowanie pojedynczych cudzysłowów we wszystkich danych wejściowych to szaleństwo. To psuje funkcjonalność aplikacji i nie jest nawet dobrym rozwiązaniem przeciwko wstrzykiwaniu SQL.

Weź pod uwagę możliwość, że źle zrozumiałeś pentestującą firmę. Jeśli jest to poważnie ich rada, to źle odbija się na pentestującej firmie i radziłbym poszukać partnera, który pomógłby odpowiednio zabezpieczyć oprogramowanie, zamiast uczynić je bezużytecznym.

Komentarze nie służą do rozszerzonej dyskusji;ta rozmowa została [przeniesiona do czatu] (https://chat.stackexchange.com/rooms/89356/discussion-on-answer-by-sjoerd-is-single-quote-filtering-nonsense).

+1 Ale tablice rejestracyjne [w Missouri mogą mieć apostrofy.] (Https://dor.mo.gov/motorv/plates/specialty.php#personalized) Numery nie powinny być przechowywane jako tekst * lub *, jeśli są (np. część pola „komentarze”), OP pokazał ciąg liczbowy w kulturze z apostrofami.[Uważaj przy zakładaniu.] (Https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/)

Christoph Burschka

2019-02-05 15:38:36 UTC

view on stackexchange narkive permalink

Jest to ewidentnie błędne w kontekście ataków typu injection - albo twoja warstwa bazy danych przetwarza łańcuchy poprawnie, albo nie. Ponieważ apostrofy są ważne w nazwach i wolnym tekście, ich całkowite zablokowanie zepsuje aplikację, a blokowanie ich wybiórczo nie rozwiązałoby problemów z wstrzykiwaniem.

Ale ścisłe sprawdzanie poprawności danych wejściowych jest dobre praktyka na zasadach ogólnych i nadmierne pobłażanie nie ma sensu w przypadkach, gdy apostrof nie jest częścią uzasadnionej wartości. Podajesz przykład 1'000'000 EUR , który jest formatem specyficznym dla ustawień regionalnych (tylko Szwajcaria, AFAIK) - ale dopuszczanie, by format był częścią wartości, nie ma tam sensu. Jeśli użytkownik wpisze 1500 , czy aplikacja powinna zapisać to tak, jak jest? Czy za każdym razem będziesz musiał decydować, czy ma być interpretowany jako 1,5 czy jako 1500? Bardziej sensowne byłoby obsłużenie prezentacji specyficznej dla lokalizacji po stronie klienta i wewnętrzne przetwarzanie wartości liczbowej w formie kanonicznej.

Zatem odpowiedź tutaj zależałaby od tego, czy audyt narzeka na określone pola tam, gdzie ma to sens, lub zalecając całkowity zakaz apostrofów. Jeśli pierwszy, to uzasadniony punkt. Jeśli to drugie, są głupie i prawdopodobnie ślepo wykonują listę kontrolną.

Zauważ, że w przypadku formatu specyficznego dla lokalizacji, najlepszą odpowiedzią może nie być zakazanie tego, ale jakoś przeanalizować i wygenerować liczbę bez tego.

@jpmc26 Liczby są łatwe: numeryczny ciąg wejściowy dostarczony przez użytkownika może zawierać liczbę całkowitą lub dziesiętną.W przypadku pierwszego po prostu upuść wszystkie niecyfrowe cyfry i kontynuuj.W przypadku liczb dziesiętnych zwykle szukam pierwszej kropki lub przecinka * od prawej do lewej * upuszczam resztę, a następnie zastępuję ją dowolnym separatorem dziesiętnym i kontynuuję.

@beppe9000 Jeszcze łatwiej byłoby skorzystać z biblioteki analizującej.Może jednak wymagać interfejsu użytkownika, aby wychwycić ustawienia regionalne użytkownika.

@jpmc26 Tak, lokalizacja należy do interfejsu użytkownika.Pobieranie danych dba tylko o normalizację: podczas obsługi stron można użyć bibliotek js do formatowania ciągów według preferencji użytkownika (czy są one przechowywane w bazie danych, czy jako plik cookie).

@beppe9000 Jak więc interpretujesz "1500" bez informacji o lokalizacji?Piętnaście setek czy półtora?

@Guran Chodzi mi o to, że wykonujesz walidację na kliencie, a następnie używasz neutralnej kultury na serwerze.Gdy chcesz wyświetlić wartość w kulturze użytkownika, sformatuj ją w js.Przechowywanie liczb jako łańcuchów jest po prostu złe, imho.

@beppe9000 True.Jednak za każdym razem, gdy otrzymujesz liczby w formacie łańcuchowym, jesteś SOL, chyba że znasz kulturę.

@Guran Jeśli tak się stanie, oznacza to, że ktoś omija walidację formularza.Więc albo spróbuj normalizacji po stronie serwera do neutralnej kultury (zgodnie z oczekiwanym typem liczby i zakresem), albo ukarz ich błędem 400.Chyba że naprawdę chcesz, aby liczby były ciągami znaków, w takim przypadku używasz bibliotek, nagłówków żądań, GeoIP i odwrotnego DNS do przybliżenia ustawień regionalnych, a jeśli wszystko zawiedzie, wyślij błąd lub przeanalizuj jako neutralne.

Joshua

2019-02-05 04:51:22 UTC

view on stackexchange narkive permalink

Krok 1) Sparametryzuj swój SQL.

Krok 2) Upewnij się, że używasz biblioteki SQL DB Connection do ustawiania wartości parametrów, nie tylko ustawiając je w tekście. To jest rzeczywista obrona przed wstrzyknięciem SQL.

Krok 3) Nie buduj zapytań w SQL. W ten sposób leży szaleństwo.

Krok 4) Dodaj przełącznik konfiguracyjny, aby propagować błąd z powrotem do użytkownika. Włącz go podczas testowania.

Krok 5) Powiedz swoim testerom penetracji, aby znaleźli sposób na wygenerowanie błędu SQL z nieparzystą liczbą pojedynczych cudzysłowów lub zamknięcie się.

+1 dla kroku 3).Absolutna prawda.

DarkMatter

2019-02-04 19:41:52 UTC

view on stackexchange narkive permalink

Przygotowane instrukcje (sparametryzowane zapytania) są świetne, po prostu upewnij się, że zostały poprawnie zaimplementowane. Widziałem implementacje „przygotowanych instrukcji”, które były równie podatne na ataki. Do omówienia szczegółów implementacji polecam przepełnienie stosu.

Również nie ma nic złego w obronie dogłębnej (w tym przypadku sprawdzanie poprawności danych wejściowych), ale zrób to dobrze ... odrzucanie wszystkich pojedynczych cudzysłowów prawdopodobnie nie jest najlepszą praktyką :)

Komentarze nie służą do rozszerzonej dyskusji;ta rozmowa została [przeniesiona do czatu] (https://chat.stackexchange.com/rooms/89473/discussion-on-answer-by-darkmatter-is-single-quote-filtering-nonsense).

Schwern

2019-02-09 05:44:27 UTC

view on stackexchange narkive permalink

Nie jestem ochroniarzem. Jestem programistą, który musi utrzymywać bezpieczny kod. To właśnie nazywam „kruchą” praktyką. Punkty wejścia są rozproszone po całym typowym projekcie. Znalezienie i odkażenie ich wszystkich to dużo pracy, aby rozwiązać tylko jeden problem, dużo starannej konserwacji i kłopotów, aby zapewnić, że pozostanie on skuteczny wraz ze zmianą kodu i pełen założeń, które czynią go nieskutecznym.

Zamiast tego stosuj praktyki, które są łatwiejsze w utrzymaniu, warstwowe, kontekstualne i rozwiązują szeroki zakres problemów. Wtedy nie potrzebujesz drogiego, zbyt szerokiego filtrowania.

Nie możesz zabezpieczyć danych wejściowych, jeśli nie wiesz, jak będą one używane.

Powiedzmy, że „zabezpieczył” system, usuwając wszystkie pojedyncze cudzysłowy ze wszystkich danych wejściowych. Świetnie, jesteś bezpieczny przed jednym typem ataku polegającego na iniekcji SQL. Co się stanie, jeśli to wejście zostanie użyte w ...

Zapytanie MySQL, które pozwala na użycie podwójnych cudzysłowów
Operacja systemu plików
Polecenie powłoki
Zapytanie sieciowe
Nazwa metody
Nazwa klasy
eval

Każda z mają one różne znaki specjalne, sekwencje ucieczki, zasady cytowania i praktyki bezpieczeństwa. Nie możesz przewidzieć, w jaki sposób twoje dane wejściowe zostaną użyte, gdy nadejdzie. Próba usunięcia wszystkich znaków specjalnych jest szaleństwem i „rozwiązuje” tylko jedną klasę ataku.

Albo co, jeśli użytkownik ma pozwolenie aby wprowadzić limit stron. Ten limit jest obowiązkowo używany w zapytaniach sparametryzowanych; bez iniekcji SQL, yay! Użytkownik wpisuje 9999999999 i teraz jesteś narażony na atak DOS.

Musisz zastosować odpowiednie środki bezpieczeństwa w miejscu, w którym wykonywana jest potencjalnie niebezpieczna operacja. Uwzględnia to wiele czynników specyficznych dla operacji; odkażanie znaków wejściowych to tylko jeden.

Dopóki to robisz, równie dobrze możesz sparametryzować swoje zapytania. Wtedy nie ma już potrzeby wykonywania całej pracy i niszczenia cytatów dotyczących usuwania koców.

Filtrowanie wszystkich danych wejściowych jest trudne.

Jest wiele, wiele, wiele sposobów pobierania i przekazywania danych wejściowych w danym projekcie:

dane wejściowe
urls
nazwy plików
zawartość pliku
zapytania do bazy danych
odczyty sieciowe
zmienne środowiskowe

Zwykle są to dość wolne formy i mogą używać wielu różnych bibliotek. Nie znam żadnych narzędzi do analizy statycznej, które sprawdzają, czy wszystkie potencjalnie wrażliwe dane przeszły przez filtrowanie. Niektóre języki mają system taint , ale ich efektywne użycie jest trudne. Nawet jeśli odfiltrujesz wszystkie dane wejściowe, bez narzędzia do analizy statycznej niefiltrowane dane wejściowe będą wyciekać z powrotem w miarę rozwoju. To dużo wysiłku w przypadku niekompletnego, kosztownego w utrzymaniu wyniku, który utrudnia funkcjonalność.

W przeciwieństwie do tego, zazwyczaj jest tylko jeden sposób wykonania SQL w projekcie. Istnieją narzędzia statyczne i wykonawcze, które automatycznie wykrywają potencjalne iniekcje SQL. Możesz nawet całkowicie zabronić ciągów i wymagać, aby wszystkie zapytania były obiektami zapytań SQL. Te dobre praktyki są łatwe w utrzymaniu i coraz częściej umieszczane w narzędziach i bibliotekach SQL.

„Zapory ogniowe” prowadzą do luźnych zabezpieczeń.

Podobnie jak w niektórych sieciach biurowych praktyki są bardzo niebezpieczne, ponieważ „ mamy firewall ”, istnieje ryzyko, że zespół będzie leniwy w kwestii zabezpieczania swojego kodu, ponieważ„ wejście jest bezpieczne ”. Dane wejściowe z całą pewnością nie są bezpieczne.

Koszt alternatywny

Ktoś mógłby powiedzieć „dlaczego nie oba?” Masz tylko tyle godzin na pracę nad projektem. Niska wydajność i wysoki poziom konserwacji są do dupy. Wdrożenie i utrzymanie go sprawi, że Twój ograniczony czas odejdzie od bardziej wydajnych i łatwiejszych w utrzymaniu praktyk. W najgorszym przypadku spędzisz tyle czasu, bawiąc się w walkę z danymi wejściowymi i późniejszymi problemami spowodowanymi przez zbyt agresywne filtrowanie, że nigdy nie będziesz miał czasu na odpowiednie środki bezpieczeństwa.

Krótko mówiąc, filtrowanie danych wejściowych jest drogie, nieszczelne, trudne w utrzymaniu, nie może rozwiązać problemu i może go pogorszyć.

Philip Rowlands

2019-02-04 19:38:58 UTC

view on stackexchange narkive permalink

Jak sam powiedziałeś, jeśli używasz zapytań parametrycznych, pojedyncze cudzysłowy nie stanowią problemu. W takim przypadku możesz odrzucić ich rady. Jeśli to zrobisz, podkreśl fakt, że używasz zapytań parametrycznych i że to również zwiększa użyteczność (korzystając z poprzednich przykładów).

Erik A

2019-02-04 21:20:11 UTC

view on stackexchange narkive permalink

Jeśli masz 100% pewności, że zawsze zapobiegasz iniekcjom SQL wszędzie, to rzeczywiście jest to nonsens.

Jednak wstrzyknięcie SQL jest jednym z najczęstszych zagrożeń bezpieczeństwa, Jeśli aplikacja została poprawnie napisana tak, aby korzystała z parametrów, niedbała DBA może wykonać zapytanie, które jest narażone na wstrzyknięcie kodu SQL drugiego rzędu. Może nawet nie być nigdzie przechowywany, może to być po prostu zapytanie o skopiowanie tabeli.

Ataki drugiego rzędu są trudniejsze do wykonania, ale trudniej jest przed nimi chronić. Ochrona przed atakami drugiego rzędu oznacza, że każda dynamiczna instrukcja SQL uruchomiona w bazie danych z uprawnieniami do zapisu musi zostać sprawdzona pod kątem ryzyka wstrzyknięcia SQL, a nie tylko instrukcji SQL przetwarzających dane wejściowe z niezaufanych źródeł.

Nie zezwalanie na cudzysłowy wszędzie jest niedbała ochrona przed atakami drugiego rzędu, ale zmniejsza ich prawdopodobieństwo. W idealnym świecie nie byłoby to konieczne, ale niestety w nim nie żyjemy.

Jeśli wielu użytkowników ma jakąkolwiek formę dostępu do zapisu w bazie danych i może pisać własne instrukcje SQL, może to być rozsądny środek bezpieczeństwa. Jeśli Twoja aplikacja jest jedynym sposobem uzyskania dostępu do bazy danych i tylko bardzo doświadczeni użytkownicy mogą wykonywać własne zapytania z prawem do zapisu, zazwyczaj nie jest to konieczne.

Wprawdzie nie jestem dobrze zorientowany w pentestingu lub PL / SQL (o czym zakładam, że o to chodzi), ale iniekcja SQL drugiego rzędu wydaje się _ naprawdę_ okropna.Jeśli wspólnie nauczyliśmy się, że używanie `eval ()` na wprowadzaniu danych przez użytkownika nie jest dobrym pomysłem, to dlaczego w takim razie używamy tego rodzaju konstrukcji w PL / SQL?Mam nadzieję, że istnieje inny sposób wykonania tego zapytania za łączem, który _nie_ przestrzega różnicy między kodem a danymi.

@tomsmeding Wstrzykiwanie drugiego rzędu jest możliwe w większości dialektów SQL (od T-SQL do `sp_executesql`, PL / SQL do` EXECUTE IMMEDIATE`, MySQL do `EXECUTE`).Wszystkie obsługują parametry, więc możesz to zrobić poprawnie, ale są ograniczenia.Na przykład przeprowadziłem migrację zapytań przestawnych Access SQL do T-SQL, a jedynym sposobem na to w T-SQL jest użycie konkatenacji ciągów w celu uzyskania dynamicznych nazw pól, tak jak robi to Access (ze znakami ucieczki, ale znaki ucieczki są złei spotkałem się z przykładowymi skryptami bez nich), ponieważ nie można używać parametrów w nazwach pól.

@tomsmeding: O ile nic się nie zmieniło, nie ma żadnego fajnego sposobu na wykonanie czegoś w formie „wybierz *, gdzie id jest w [lista]” bez użycia dynamicznie generowanego kodu SQL do określenia listy.Nie próbowałbym czegoś takiego z pozycjami określonymi przez użytkownika na liście, ale w przypadku identyfikatorów numerycznych przetwarzanych za pomocą liczbowych typów danych nie widzę żadnego ryzyka wstrzyknięcia.

@supercat z pewnością można to zrobić - na przykład dla python / postgres robi się to tak jak http://initd.org/psycopg/docs/usage.html#lists-adaptation lub http://initd.org/psycopg/docs/use.html # krotki-adaptacja, więc istnieje wsparcie dla sterowników i podobne funkcje powinny być dostępne dla innych języków / silników DB.

@Peteris: Czy biblioteka Psycopg przekazuje tablice do silnika SQL jako parametry, czy też rozszerza je jako polecenie, które pobiera zmienną liczbę indywidualnych parametrów, czy co?

@supercat Nie mogę być pewien bez zagłębiania się w wewnętrzne elementy psycopg2, niż mówią dokumenty API, ale ponieważ tablice są rodzimym typem danych postgresql (https://www.postgresql.org/docs/9.0/arrays.html), jest to możliwe (a zatem konieczne do obsługi) jako wartość dla kolumn w dowolnym losowym SELECT, wtedy założyłbym, że sterownik musi obsługiwać wymianę tablic w odpowiedniej formie, a nie jakiś ciąg znaków.

PostgreSQL zapewnia znacznie lepszą ochronę przed wstrzyknięciem do zapytań `EXECUTE IMMEDIATE`: zestaw funkcji, które będą poprawnie cytować dane wejściowe.Są to [`quote_ident`] (https://www.postgresql.org/docs/current/functions-string.html#id-1.5.8.9.7.2.2.21.1.1), [` quote_literal`] (https: //www.postgresql.org/docs/current/functions-string.html#id-1.5.8.9.7.2.2.22.1.1) i [`quote_nullable`] (https://www.postgresql.org/docs/current/functions-string.html#id-1.5.8.9.7.2.2.24.1.1).Oczywiście preferowane jest unikanie polecenia „WYKONAJ NATYCHMIAST”, ale są to światy lepsze w odkażaniu, jeśli musisz go użyć.

@supercat Nie wiem konkretnie o psycopg2, ale wiem, że niektóre biblioteki klienta rozszerzają tablicę do indywidualnych parametrów dla niektórych baz danych, takich jak `IN (: p1,: p2,: p3 ...)`.Więc to przynajmniej jedna technika.

@supercat Czy nie zrobiłbyś po prostu czegoś takiego jak `wybierz nazwę użytkownika z karty użytkownika dołącz do zakładki sesji na usertab.id = sessiontab.id, gdzie session.token = `?Wydaje mi się, że może wydajność, ale takie pełne sprzężenie i tak zostaje zoptymalizowane przez planer zapytań, a nawet jeśli z jakiegoś powodu tak się nie stało, nadal można to wymusić, dołączając do podzapytania.

@IMSoP Jest to odniesienie do przykładu podanego w odpowiedzi.Po prostu używam `` do oznaczenia dowolnej przygotowanej składni instrukcji, której sterownik SQL potrzebuje do rzeczywistej operacji.Jeśli chodzi o klauzulę `IN` dostarczoną przez użytkownika, to nie o to mi chodzi;raczej w połączonym przykładzie iniekcja SQL drugiego rzędu wydaje się, że jest to głównie konsekwencja użycia jakiegoś rodzaju szarpanego rozwinięcia ciągów w trakcie zapytania.Nie jestem ekspertem od DBA, ale nie jest to zbyt dobry dowód na to, dlaczego może być konieczne uruchomienie zapytania, które byłoby podatne na ten problem w pierwszej kolejności.

Kiedyś to zrobiłem.Każdy ciąg użytkownika został natychmiast zakodowany w htmlencoded.Teraz uważam, że to zły wybór architektoniczny.

@AJMansfield OK, byłem zdezorientowany, ponieważ Twój komentarz był skierowany do `supercat`, więc pomyślałem, że dotyczy to ich przykładu" select * where id is in [list] ", a nie odpowiedzi (która została napisana przez kogoś innego).

@IMSoP Och, ups!Właściwie nie chciałem nikogo oznaczać ...

Tobi Nary

2019-02-04 19:38:39 UTC

view on stackexchange narkive permalink

Chociaż nie znam szczegółów Twojej aplikacji, podążam za Twoim argumentem.

Istnieją pola, które nie muszą zawierać określonych znaków. Dzięki tym polom możesz użyć sprawdzania poprawności danych wejściowych do filtrowania pojedynczych cudzysłowów (i podwójnych cudzysłowów itp.).

Jeśli twój znak ucieczki nie działał poprawnie, walidacja danych wejściowych może być strategia łagodzenia skutków, ale używanie przygotowanych instrukcji (poprawnie) powinno być preferowanym podejściem do ograniczania ryzyka iniekcji SQL.

Jason Leaman

2019-02-05 16:14:23 UTC

view on stackexchange narkive permalink

Jeśli jest to wynik prawdziwego testu penetracji, powinni być w stanie przedstawić wartość do przesłania, która dowodzi, że jest to problem, który można wykorzystać. Jeśli nie mogą, zasugerowałbym poproszenie o odpowiedni test penetracyjny, w którym udowodnią, że można to wykorzystać.

Jeśli jednak jest to wynik ogólnego Skanowania luk w zabezpieczeniach, spodziewałbym się rozmytych ogólnych odpowiedzi, takich jak ta, że po prostu oznaczyłby możliwość wstawienia pojedynczego cudzysłowu. W takim przypadku, jeśli jesteś zadowolony, że nie ma problemu, możesz z radością zignorować ten wynik.

Ta odpowiedź tak naprawdę nie odpowiada na pytanie.Pytanie nie dotyczy metodologii testowania, ale sposobu filtrowania.Upewnij się, że Twoje odpowiedzi dotyczą bezpośrednio pytania.Uwielbiamy różne perspektywy i informacje, ale wydaje się to być styczne.

@schroeder: Mówi na dwa sposoby "więc możesz wpisać pojedynczy cudzysłów, teraz gdzie jest luka?"a druga podważa ramkę, że odfiltrowywanie pojedynczych cudzysłowów jest dobre dla bezpieczeństwa.

@schroeder Pytanie brzmi: „Co powinienem zrobić z tym raportem z testu penetracji?”Ta odpowiedź brzmi: „Sprawdź, czy jest to prawdziwa luka, a jeśli nie, zignoruj ją jako fałszywie pozytywną”.Nie jestem pewien, dlaczego miałoby to być styczne.

@IMSoP to wcale nie jest pytanie, to jest meta abstrakcja pytania.Jeśli w rzeczywistości jest to pytanie, wówczas PO udziela odpowiedzi własnych (PO zarysowuje tę odpowiedź).

@Joshua OP szczególnie rzuca wyzwanie ramie w bardzo szczegółowy sposób, więc znowu nie jestem pewien, co zapewnia ta odpowiedź.

@schroeder Nie jestem pewien, co masz na myśli przez „meta abstrakcję”.Dosłowny tekst pytania kończy się „Czy powinniśmy odrzucić implementację sprawdzania poprawności danych wejściowych dla pojedynczych cudzysłowów z powodów, które podałem?”Dosłowny tekst tej odpowiedzi kończy się „W takim przypadku… możesz z radością zignorować ten wynik”.To nie jest najbardziej szczegółowa odpowiedź, ale jest odpowiedzią.

@scheoeder: Jest to w dużej mierze oszustwo innych odpowiedzi, ale NAA powinno być używane tylko wtedy, gdy nawet jeśli byłaby to jedyna odpowiedź, jest zła.

Ale w tym przypadku pożądana jest duża liczba odpowiedzi mówiących, że pentestry są błędne.

@IMSoP 2 zacytowane stwierdzenia nie są ze sobą w żaden sposób powiązane

@schroeder Nie jestem pewien, o ile bardziej mogą być spokrewnieni."Czy powinniśmy X?"„Jeśli Y, to tak”.

MrNiceGuy

2019-02-04 21:27:11 UTC

view on stackexchange narkive permalink

Od byłego programisty stron internetowych, a teraz sam jestem testerem pióra, nie chciałbym ograniczać możliwości wprowadzania danych przez użytkownika, ale może to być poważny problem. Wiem, że sam użyłem tej techniki do włamania się do aplikacji internetowych i baz danych.

Moim zdaniem byłoby sprawdzenie instalacji bazy danych i konfiguracji języka internetowego (php) pod kątem obsługi znaków ucieczki, a następnie zakodowanie modułów do iteracji danych wejściowych, aby upewnić się, że jest odpowiednio sformatowana.

Apostrof może być prawidłowym wejściem, ale może również uniknąć przekazania instrukcji bazy danych i wprowadzić wektor ataku. DB i języki internetowe mają moduły, które mogą obsługiwać tego typu instancje, ale nadal dobrym pomysłem jest napisanie własnego modułu do podwójnego sprawdzenia.

OP ma wszystko odpowiednio sparametryzowane, więc znaki zmiany znaczenia nie powinny być nigdzie używane.Ponadto [nie zawsze zapewniają bezpieczeństwo] (https://stackoverflow.com/a/12118602/7296893), nawet jeśli są odpowiednio zaimplementowane.

Zgoda, w zależności od stosu i frameworków, których używasz, dodatkowe testy poprawności mogą być przydatne.W moim przypadku używam Java / JDBC z przygotowanymi instrukcjami, zamiast Spring Data JPA, ze sparametryzowanymi zapytaniami JPQL - to jest dość solidne.

ANone

2019-02-12 20:05:06 UTC

view on stackexchange narkive permalink

Myślę, że to kwestia perspektywy. Twój system ma wymagania funkcjonalne, które powinny być pierwsze. Nie oznacza to, że nie warto rozważać kwestii walidacji danych wejściowych. Przy okazji, te dwie rzeczy nie są ze sobą bezpośrednio sprzeczne. Nie polecam tego, ale byłoby możliwe kodowanie i dekodowanie w interfejsie użytkownika oraz przechowywanie i zapytania SQL w postaci zakodowanej.

Równowaga jest subiektywna i zależy od wielu rzeczy nie wspomniany. Możesz poprosić ich o wyjaśnienie. Mogą mieć bardzo dobry powód, mogą nie.

Dewi Morgan

2019-02-05 09:22:48 UTC

view on stackexchange narkive permalink

Zaprzeczę większości innych aktualnych odpowiedzi.

Twoje pentestry są prawie na pewno w 100% poprawne.

Moje założenie: nie warto pentestera ich sól zgłosiłaby to, chyba że stwierdziliby, że Twoja aplikacja przyjęła i powtórzyła apostrofy w sytuacji, gdy żadne apostrofy nie były ważne.

Być może Twoje nazwy użytkowników, numery telefonów, nazwy domen i daty powinny mieć określone formaty i zakresy znaków. Wszystkim powinno brakować apostrofów. Ale zamiast tego akceptujesz po prostu każdy stary ciąg, który ci podają, dla wszystkich tych pól.

Jeśli to założenie jest fałszywe i już sprawdzasz swoje dane wejściowe tak ściśle, jak to tylko możliwe, są błędne i wszystko w porządku.

Jeśli to założenie jest prawdziwe i apostrofy byłyby nieprawidłowe w danych wejściowych, to:

Tak, powinieneś od razu odrzucać nieprawidłowe dane wejściowe.
Nie powinieneś nie pozwalać ludziom na zanieczyszczanie Twojej bazy danych uszkodzonymi danymi.
Powinieneś nie próbuj czyścić tych danych podczas wyświetlania, tak samo jak próbujesz wyczyścić <script> , ponieważ atakujący po prostu znajdzie sposób na wykorzystanie twojego czyszczenia algorytm, taki jak <script > lub <scr<script>ipt> lub + ADw-script + AD4- lub cokolwiek innego.
Masz rację. są wyjątki, ale należy je jasno zdefiniować jako pkt szczególne przypadki: nie powinny być uważane za normę.
O ile twoje wymagania nie dotyczą obsługi regionalnych walut szwajcarskich z apostrofami w, Twój przykład „1'000'000” nie jest bardziej prawidłową liczbą całkowitą niż „ 1 ~ 000 ~ 000 ”lub„ 1banana000apple000 ”. Odrzuć to. Nie próbuj czyścić „1000”, nie wiesz, czy oznacza ono 1000, 1000, 14000, stopę lub stopień, czy coś zupełnie innego.

Parametryzacja zapytań pozwala uniknąć tylko większości klas wstrzyknięć SQL : nie wszystkie możliwe nadużycia nieprawidłowych danych.

Ale co z wszystkimi innymi systemami, które polegasz na nazwie użytkownika zgodnej ze standardem firmy? Właśnie je złamałeś.

Czy użytkownicy mają katalogi domowe? To będzie problem.
Czy ich nazwy są gdziekolwiek rejestrowane?
Czy kiedykolwiek są wyświetlane?
Czy nazwy użytkowników są kiedykolwiek używane w parametrach poleceń systemu wywołania?
Czy kiedykolwiek wysyłają dane AJAX lub XML?
Czy są jakieś operacje w trybie wsadowym, które działają na paczkach nazw użytkowników, powiedzmy nazwy zaczynające się od A do M pewnego dnia, N do Z następnego, 0-9 trzeciego dnia, potem powtórz? Te partie nigdy nie będą działać przeciwko Twojemu użytkownikowi '-_haxxor_-'.
Czy są przypadki, w których udawanie innego użytkownika byłoby dla kogoś szkodliwe lub przydatne, więc chcesz, aby wszyscy mają unikalne nazwy? Ale mogą udawać użytkownika John, rejestrując się jako John Ϳο ո Јо հ lub Ꭻ օ.
Wszystkie systemy, które używają nazwy nie mogą odrzucić podanej przez Ciebie wartości. Zamiast tego będą miały do obsługi nieprawidłowych danych wejściowych, próby ich wyczyszczenia lub ucieczki, mimo że już pokazaliśmy, że jest to niebezpieczne i skazane na niepowodzenie. Ale ponieważ użytkownik już dawno się wylogował, nie zobaczy żadnego błędu wymagającego podania nowego adresu e-mail.
Twój DBA ma teraz bzdury w swojej bazie danych. Spowoduje to wiele bólu nie tylko w codziennej pracy, ale także wtedy, gdy będzie musiał migrować te dane, ponieważ wszelkie ściślejsze ograniczenia w systemie docelowym zerwą stare dane.
Twoi koledzy a inni konsumenci twoich danych muszą teraz sprawdzać wszystko, co czytają z bazy danych, ponieważ nie mogą ci ufać, że egzekwujesz nawet w pełni udokumentowane standardy.
Twoi użytkownicy używają teraz mniej bezpiecznego systemu.
Musisz teraz przejść i przerobić wszystkie te dane wejściowe, aby upewnić się, że nie wprowadzasz już bzdur do bazy danych.

Parametryzacja zapytań nie jest alternatywą dla prawidłowego oczyszczania danych wejściowych.

Pozwól nam [kontynuować tę dyskusję na czacie] (https://chat.stackexchange.com/rooms/89352/discussion-between-dewi-morgan-and-lightness-races-in-orbit).

Wygląda na to, że mój komentarz został usunięty podczas masowego czyszczenia, więc powtórzę dla tych, którzy nie są pewni, dlaczego ta odpowiedź jest negatywna: ** wejście odkażające nie zastąpi prawidłowego przetwarzania danych na wyjściu **.Spośród przykładów podanych w tej odpowiedzi tylko przypadek podszywania się jest rozsądny do wdrożenia tylko na wejściu.Każda z pozostałych ** tylko ** może być poprawnie obsługiwana przez ucieczkę lub filtrowanie danych ** tam, gdzie są przetwarzane **.Sprawdzanie poprawności danych wejściowych jest przydatne do przekazywania opinii użytkownikom, ale zwiększy bezpieczeństwo tylko wtedy, gdy robisz coś złego w innym miejscu.

@IMSoP: Kłócisz się ze słomianem.Jeśli możesz wskazać, skąd masz fałszywe przekonanie, że powiedziałem: „odkażanie danych wejściowych jest substytutem prawidłowego postępowania z danymi wyjściowymi”, mogę to naprawić.ALE NIE POWIEDZIAŁEM TEGO.Powiedziałem, że „parametryzacja zapytań nie jest alternatywą dla prawidłowego oczyszczenia danych wejściowych”.Nawet pogrubiłem to i wszystko.Czy ludzie nie rozumieją tutaj różnicy?Uważam, że konsekwencje takiego zamieszania dla bezpieczeństwa są raczej przerażające.

Parametryzacja zapytań * oraz jej odpowiednik wszędzie tam, gdzie używasz danych *, ** jest ** alternatywą dla odkażania danych wejściowych;w istocie jest to ** lepsza alternatywa **, jeśli Twoim celem jest bezpieczeństwo.Powiedzenie „twoja nazwa użytkownika nie może zawierać apostrofu” może być uspokajające, ale jedyne, co mówi atakującemu, to „muszą używać tego w jakimś nieprzetworzonym zapytaniu. Powinienem znaleźć sposób, aby skłonić go do stworzenia użytkownika zapostrof w „.Jeśli nie masz 100% pewności, że walidacja wychwyci każdy problem i nie ma możliwości ominięcia go, musisz bronić się przed złymi danymi podczas ich używania.

Zasadniczo problem z traktowaniem oczyszczania wejściowego jako środka bezpieczeństwa polega na tym, że nie ma czegoś takiego jak „bezpieczne dane”;bezpieczeństwo zależy od kontekstu, w którym go używasz.Ponieważ nie możesz przewidzieć każdego możliwego kontekstu, jaki będziesz mieć w czasie życia danych, możesz albo ograniczyć swoje funkcje i użyteczność, ograniczając każde pole do A-Z, a-z, 0-9;lub możesz potraktować oczyszczanie jako niekompletny środek poparty "prawdziwym" zabezpieczeniem wpisanym w każdy napotkany kontekst.

@IMSoP: Walidacja, parametryzacja i ucieczka wyjścia to trzy ortogonalne osie bezpieczeństwa wprowadzania danych przez użytkownika.Brak któregokolwiek z nich to luka w zabezpieczeniach.Przepełnienia bufora, przepełnienia liczb całkowitych, opisany przeze mnie problem zakresu wsadowego cron i niezliczone ataki na wykonanie dowolnego kodu są łagodzone przez poprawną i wielowarstwową walidację, ale pozostałe dwie osie nie mają na nie wpływu.

Nie widzę, w jaki sposób na problem grupowania zakresów „nie miałyby wpływu pozostałe dwie osie”.** Jeśli ** wiesz, że możesz w 100% ufać, że wszystkie dane wejściowe będą alfanumeryczne, opisany algorytm jest akceptowalny;ale w bardzo prawdopodobnym przypadku tak nie jest, musisz dodać asercję, która ostrzega operatora lub klauzulę „i cokolwiek innego”.Dlatego najbezpieczniejszym rozwiązaniem jest to, które jest najbliżej przetwarzania, a nie to, które ufa, że dane wejściowe z 10 lat wcześniej przewidywały scenariusz.

Zrobiłbym -1 gdybym mógł ... "Żaden pentester wart swojej soli nie miałby ..." Czy nie chodzi o to, aby cały problem dotyczył ustalenia, czy pentester jest wart swojej soli?- Pentester powiedział X, czy mają rację?Zakładanie, że pentester tak naprawdę nie powiedział „X”, całkowicie mija się z celem.

„Jeśli możesz wskazać, skąd masz fałszywe przekonanie, że powiedziałem„ odkażanie danych wejściowych jest substytutem prawidłowego postępowania z danymi wyjściowymi ”,” - Ten cytat: „Ale co z wszystkimi innymi systemami, które opierają się na nazwie użytkownika zgodnej ze standardem firmy? Właśnie je złamałeś. "konkretnie stwierdza, że systemy, które używają danych wejściowych z tej aplikacji, zepsują się, _ ponieważ_ ta aplikacja nie dezynfekuje.(alternatywą jest to, że nie pękną, jeśli to się odkaży). Silna implikacja jest taka, że warunki sanitarne są jedyną warstwą obrony.