Kiedy najlepiej dezynfekować wkład użytkownika?

Dezynfekuję swoje dane użytkownika, podobnie jak Radu...

1. Pierwsza strona klienta używająca zarówno regex, jak i przejmująca kontrolę nad dozwolonymi znakami wprowadzanie danych do podanych pól formularza przy użyciu javascript lub jQuery związanych ze zdarzeniami, np. onChange lub OnBlur, który usuwa wszelkie niedozwolone dane wejściowe, zanim jeszcze będzie / align = "left" / Uświadomić sobie jednak, że to naprawdę ma tylko efekt pozwalając tym Użytkownicy wiedzą, że dane będą sprawdzane również po stronie serwera. On bardziej Ostrzeżenie niż jakąkolwiek rzeczywistą ochronę.

2. Po drugie, i Rzadko widuję to robione w tych dniach już, że pierwszy czek jest zrobione po stronie serwera jest sprawdzenie lokalizacji skąd jest przesyłany formularz. Zezwalając tylko na przesyłanie formularza ze strony, która została oznaczona jako ważna lokalizacja, możesz zabić skrypt, zanim jeszcze przeczytasz jakiekolwiek dane. Przyznane, to samo w sobie jest niewystarczające, ponieważ dobry haker z własnym serwerem może "fałszować" zarówno domeny jak i adresu IP do spraw, aby twój skrypt zdawał sobie sprawę, że nadchodzi z prawidłowej lokalizacji formularza.

3. Dalej, i nie powinienem nawet tego mówić, ale zawsze, i mam na myśli zawsze, biegnij Twoje skrypty w trybie skażenia. Zmusza to do nie lenistwa i do pilnego Krok 4.

4. Jak najszybciej wyczyścić dane Użytkownika za pomocą dobrze uformowanych wyrażeń regularnych odpowiednich do dane, których oczekuje się od dowolnego pola w formularzu. Nie idź na skróty jak the infamous ' magiczny róg jednorożca ' aby przebić się przez twoje splamione czeki... albo równie dobrze możesz po prostu wyłączyć sprawdzanie skażenia na pierwszym miejscu dla wszystkich dobrych zrobi to dla Twojego bezpieczeństwa. To tak, jakby dać psychopacie ostry nóż, niosąc twoje gardło i powiedzenie "naprawdę nie skrzywdzisz mnie tym zrobisz".

   I tutaj różnię się od większości innych w tym czwartym kroku, ponieważ tylko odkażam dane użytkownika, które zamierzam faktycznie wykorzystać w sposób, który może przedstawić bezpieczeństwo ryzyka, np. wszelkie wywołania systemowe, przypisania do innych zmiennych lub zapis do przechowuj dane. Jeśli używam tylko danych wprowadzonych przez użytkownika do porównania z danymi Sam zapisałem w systemie (dlatego wiedząc, że własne dane są bezpieczne), wtedy nie zawracam sobie głowy dezynfekowaniem danych użytkownika, ponieważ nigdy nie pójdę do nas w ten sposób to stanowi problem bezpieczeństwa. Na przykład, przyjmij nazwę użytkownika jako przykład. Używam nazwy użytkownika wprowadzonej przez użytkownika tylko do sprawdzenia przeciwko meczowi w mojej bazy danych, a jeśli jest prawdziwa, to po tym używam danych z bazy danych do wykonywania wszystkie inne funkcje, które mogę wywołać w skrypcie, wiedząc, że jest bezpieczny i nigdy użyj danych użytkowników ponownie po tym.

5. Ostatni, to odfiltrować wszystkie próby autouzupełniania przez roboty w dzisiejszych czasach, z system "Uwierzytelniania przez człowieka", taki jak Captcha. To jest wystarczająco ważne w dzisiejszych czasach że poświęciłem czas na napisanie własnego "ludzkiego" schematu, który wykorzystuje zdjęcia i wejście dla "człowieka", aby wprowadzić to, co widzą na zdjęciu. Zrobiłem to, ponieważ Odkryłem, że systemy typu Captcha bardzo denerwują użytkowników (można powiedzieć po ich zmrużone oczy od próby rozszyfrowania zniekształconych liter... Zwykle ponad i jeszcze raz). Jest to szczególnie ważne w przypadku skryptów używających Sendmaila lub SMTP do poczty e-mail, ponieważ są to ulubione dla głodnych spam-botów.

Podsumowując to w skrócie, wyjaśnię to tak, jak robię to mojej żonie... Twój serwer jest jak popularny klub nocny, a im więcej masz bramkarzy, tym mniej problemów możesz mieć w nocnym klubie. Mam dwóch bramkarzy na zewnątrz drzwi (Walidacja po stronie klienta i uwierzytelnianie przez człowieka), jeden bramkarz bezpośrednio w drzwiach (sprawdzanie poprawnej lokalizacji składania formularza... 'Czy to naprawdę ty na tym ID'), a jeszcze kilku bramkarzy w bliskość drzwi (Uruchamianie trybu zaciemniania i używanie dobrych wyrażeń regularnych do sprawdzania dane użytkownika).

Wiem, że to starszy post, ale czułem, że to wystarczająco ważne, aby każdy, kto może przeczytać go po mojej wizycie tutaj, aby uświadomić sobie, że ich nie jest " magiczna kula", jeśli chodzi o bezpieczeństwo, a to wymaga wszystkich tych prac w połączeniu ze sobą, aby Twoje dane dostarczone przez użytkownika były bezpieczne. Samo użycie jednej lub dwóch z tych metod jest praktycznie bezwartościowe, ponieważ ich moc istnieje tylko wtedy, gdy wszyscy współpracują ze sobą.

Lub w podsumowaniu, jak często mawiała moja mama... "Lepiej być bezpiecznym niż żałować".

Niestety, prawie nikt z uczestników nigdy nie zrozumiał jasno, o czym mówią. Dosłownie. Tylko @Kibbee udało się to wyprostować.

Ten temat dotyczy dezynfekcji. Ale prawda jest taka, że coś takiego jak szeroko rozumiana "dezynfekcja ogólnego przeznaczenia", o którym wszyscy tak chętnie mówią, po prostu nie istnieje.

Istnieje milion różnych nośników, każdy wymaga własnego, odrębnego formatowania danych. ponadto-nawet pojedynczy określony nośnik wymaga innego formatowania dla jego części . Powiedzmy, formatowanie HTML jest bezużyteczne dla javascript osadzonego na stronie HTML. Lub, formatowanie łańcuchów jest bezużyteczne dla liczb w zapytaniu SQL.

W rzeczywistości, takie "odkażanie jak najwcześniej", jak sugeruje większość upvoted odpowiedzi, jest po prostu niemożliwe . Ponieważ po prostu nie można powiedzieć, w którym pewnym medium lub medium dane będą używane. Przygotowujemy się do obrony przed "SQL-injection", uciekając przed wszystkim, co się rusza. Ale UPS! - niektóre wymagane pola nie zostały wypełnione i musimy wypełnić dane z powrotem do formularza zamiast bazy danych... z dodanymi ukośnikami.

Z drugiej strony, pilnie uniknęliśmy wszystkich "wejść użytkownika"... ale w zapytaniu sql nie mamy cudzysłowów wokół niego, ponieważ jest to Liczba lub identyfikator. I Żadna "dezynfekcja" nam nie pomogła.

Z trzeciej strony-OK, zrobiliśmy wszystko, co w naszej mocy, aby dezynfekować okropnego, niegodnego zaufania i pogardzanego "użytkownika input"... ale w pewnym wewnętrznym procesie wykorzystaliśmy te same dane bez formatowania (tak jak robiliśmy co w naszej mocy!- i UPS! dostali zastrzyk drugiego rzędu w całej okazałości.

Więc, z punktu widzenia prawdziwego użytkowania życia, jedynym właściwym sposobem byłoby

• formatowanie, nie cokolwiek "dezynfekcja"
• tuż przed użyciem
• zgodnie z pewnymi zasadami medium
• a nawet przestrzeganie pod-zasad wymaganych dla różnych części tego medium.

To zależy od tego, jaki rodzaj dezynfekcji robisz.

W celu ochrony przed SQL injection, nie rób nic z samymi danymi. Wystarczy użyć gotowych instrukcji, a w ten sposób nie musisz się martwić o mieszanie się z danymi wprowadzonymi przez użytkownika, a to negatywnie wpływa na Twoją logikę. Musisz trochę zdezynfekować, aby upewnić się, że liczby są liczbami, a Daty są datami, ponieważ wszystko jest ciągiem znaków, ponieważ pochodzi z żądania, ale nie próbuj robić żadnego sprawdzania aby robić rzeczy takie jak blokowanie słów kluczowych lub cokolwiek innego.

W celu ochrony przed atakami XSS, prawdopodobnie łatwiej byłoby naprawić dane przed ich zapisaniem. Jednak, jak inni wspominali, czasami miło jest mieć nieskazitelną kopię dokładnie tego, co wpisał użytkownik, ponieważ po zmianie to przepada na zawsze. Szkoda, że nie ma głupiego sposobu na zapewnienie, że aplikacja wypuści tylko sanitized HTML tak, jak możesz zapewnić, że nie zostaniesz złapany przez SQL injection za pomocą przygotowanego zapytania.

Wcześnie jest dobry, na pewno zanim spróbujesz go przeanalizować. Wszystko, co masz zamiar wyjść później, lub szczególnie przekazać do innych komponentów (np. powłoka, SQL, itp.) musi być zdezynfekowane.

Ale nie przesadzaj - na przykład hasła są haszowane przed ich przechowywaniem (prawda?). Funkcje Hash mogą akceptować dowolne dane binarne. I nigdy nie wydrukujesz hasła (prawda?). Więc nie analizuj haseł - i nie oczyszczaj ich.

Również upewnij się, że robisz dezynfekcję z zaufanego procesu - JavaScript / cokolwiek po stronie klienta jest gorsze niż bezużyteczne bezpieczeństwo/integralność-wise. (Może to zapewnić lepsze wrażenia użytkownika, aby zawieść na początku - po prostu zrób to w obu miejscach.)

Najważniejszą rzeczą jest zawsze być konsekwentnym w czasie ucieczki. Przypadkowe podwójne odkażanie jest lamerskie, a nie odkażanie jest niebezpieczne.

Dla SQL, po prostu upewnij się, że biblioteka dostępu do bazy danych obsługuje zmienne bind, które automatycznie uciekają wartości. Każdy, kto ręcznie łączy dane wejściowe użytkownika z łańcuchami SQL powinien wiedzieć lepiej.

Dla HTML, wolę uciec w ostatniej możliwej chwili. Jeśli zniszczysz dane wejściowe użytkownika, nigdy go nie odzyskasz, a jeśli zrobią błąd, który mogą później edytować i naprawić. Jeśli zniszczysz ich oryginalny wkład, zniknie na zawsze.

Perl ma opcję taint, która uważa wszystkie dane wejściowe użytkownika za "skażone", dopóki nie zostanie sprawdzone za pomocą wyrażenia regularnego. Skażone dane mogą być używane i przekazywane, ale skażają wszelkie dane, z którymi się stykają, dopóki nie zostaną nieskażone. Na przykład, jeśli Dane wejściowe użytkownika są dołączane do innego łańcucha, nowy łańcuch jest również skażony. Zasadniczo każde wyrażenie zawierające skażone wartości wyświetli skażony wynik.

Skażone dane mogą być rzucane do woli (skażanie danych w miarę), ale jak tylko zostanie użyty przez polecenie, które ma wpływ na świat zewnętrzny, skrypt Perla zawiedzie. Więc jeśli użyję splamionych danych do stworzenia pliku, zbuduję polecenie powłoki, zmienię katalog roboczy itp, Perl zawiedzie z błędem bezpieczeństwa.

Nie znam innego języka, który ma coś w rodzaju "skażenia", ale używanie go było bardzo otwierające oczy. To niesamowite, jak szybko skażone dane rozprzestrzeniają się, jeśli nie usuniesz ich od razu. Rzeczy, które naturalne i normalne dla programista, jak ustawienie zmiennej na podstawie danych użytkownika lub otwarcie pliku, wydaje się niebezpieczny i ryzykowny przy włączonym taintingu. Więc najlepszą strategią dla getting rzeczy zrobić jest untaint, jak tylko otrzymasz pewne dane z zewnątrz.

I podejrzewam, że jest to najlepszy sposób również w innych językach: zweryfikuj dane użytkownika od razu, aby błędy i luki w zabezpieczeniach nie mogły rozprzestrzeniać się zbyt daleko. Ponadto powinno być łatwiejsze Sprawdzenie kodu pod kątem luk w zabezpieczeniach, jeśli potencjalne luki znajdują się w jednym miejscu. Oraz nigdy nie można przewidzieć, które dane zostaną później wykorzystane w jakim celu.

Moim zdaniem jest dezynfekcja wejścia użytkownika jak tylko po stronie klienta i serwera, robię to tak

1. (Po stronie klienta), pozwala użytkownikowi na wprowadź tylko określone klucze w polu.
2. (Po stronie klienta), gdy użytkownik przejdzie do następnego pola używając onblur, przetestuj dane wejściowe, które wprowadził przed wyrażeniem regularnym i zwróć uwagę na użytkownika, jeśli coś nie jest dobre.
3. (Po stronie serwera), przetestuj ponownie wejście, if field should be INTEGER sprawdź to (w PHP możesz użyć is_numeric() ), jeśli pole ma dobrze znany format sprawdź go przed wyrażeniem regularnym, wszystkie inne (np. komentarze tekstowe), tylko ucieknij im. Jeśli coś jest podejrzane, zatrzymaj wykonywanie skryptu i zwróć Użytkownikowi powiadomienie, że dane, które enetered in są nieprawidłowe.

Jeśli coś naprawdę wygląda jak atak posible, skrypt wysyła wiadomość e-mail i SMS do mnie, więc mogę sprawdzić i Maibe zapobiec go tak szybko, jak posible, muszę tylko sprawdzić dziennik, w którym jestem loggin wszystkie wejścia użytkownika, i kroki skrypt wykonane przed zaakceptowaniem wejście lub odrzucenie go.

Wyczyść dane przed ich zapisaniem. Ogólnie rzecz biorąc, nie powinieneś preformować żadnych akcji SQL bez uprzedniego czyszczenia danych wejściowych. Nie chcesz narażać się na atak SQL injection.

Przestrzegam tych podstawowych zasad.

1. modyfikują tylko akcje SQL, takie jak, INSERT, UPDATE, DELETE poprzez POST. Nigdy.
2. uciec od wszystkiego.
3. jeśli oczekujesz, że dane wejściowe użytkownika będą czymś, upewnij się, że to jest to coś. Na przykład: żądasz numeru, a następnie upewnij się, że jest to numer. Użyj walidacji.
4. Użyj filtrów. Oczyść niechciane postacie.

Użytkownicy są źli!

No może nie zawsze, ale moje podejście polega na natychmiastowym sanatyzowaniu, aby upewnić się, że nic ryzykownego nie zbliży się do mojego zaplecza.

Dodatkową korzyścią jest to, że możesz dostarczyć feed back do użytkownika, jeśli dezynfekujesz w punkcie wejścia.

Załóżmy, że wszyscy użytkownicy są złośliwi. Odkaż wszystkie wejścia tak szybko, jak to możliwe. Kropka.

Oczyszczam swoje dane tuż przed ich przetwarzaniem. Być może będę musiał wziąć pola Imię I Nazwisko i połączyć je w trzecie pole, które zostanie wstawione do bazy danych. Zamierzam wyczyścić wejście, zanim nawet zrobię konkatenację, więc nie dostaję żadnych błędów przetwarzania lub wstawiania. Im szybciej, tym lepiej. Nawet Korzystanie z Javascript na froncie (w konfiguracji internetowej) jest idealne, ponieważ będzie to miało miejsce bez żadnych danych trafiających do serwera na początek.

The przerażające jest to, że możesz nawet chcieć rozpocząć dezynfekcję danych pochodzących z twojej bazy danych. Niedawny wzrost ataków ASPRox SQL Injection, które miały miejsce, jest podwójnie śmiertelny, ponieważ zainfekuje wszystkie tabele bazy danych w danej bazie danych. Jeśli twoja baza danych jest hostowana gdzieś, gdzie w tej samej bazie danych znajduje się wiele kont, Twoje dane zostaną uszkodzone z powodu błędu kogoś innego, ale teraz dołączyłeś do grona hostujących złośliwe oprogramowanie dla odwiedzających nie z własnej winy.

Jasne, że to wymaga dużo pracy z góry, ale jeśli dane są krytyczne, to jest to godna inwestycja.

Uważam, że natychmiastowe czyszczenie ma dwie zalety. Po pierwsze, możesz potwierdzić to i przekazać opinię użytkownikowi. Po drugie, nie musisz się martwić o zużywanie danych w innych miejscach.

Dane wejściowe użytkownika powinny być zawsze traktowane jako złośliwe przed przeniesieniem ich do niższych warstw aplikacji. Zawsze wykonuj dezynfekcję danych wejściowych tak szybko, jak to możliwe i z jakiegokolwiek powodu nie powinny być przechowywane w bazie danych przed sprawdzeniem złośliwych intencji.