Odrzucanie złośliwych żądań

Question

Niedawno przejąłem aplikację, a ostatnio zrobiliśmy appscan i dostałem przedmiot oznaczony jako wrażliwy. Zadaniem remediacji, które sugerował raport, było odrzucenie złośliwych żądań. Raport mówi AppScan próbowałem:

Następujące zmiany zostały zastosowane do pierwotnego wniosku: zestaw nagłówek HTTP „http://bogus.referer.ibm.com”

miałem ten oznaczony 1 raz wpadliśmy AppScan i umieścić kod do sprawdź, czy jest dostępny adres URL, jeśli tak, upewnij się, że jest taki sam, jak host w adresie URL, w przeciwnym razie zabij sesję użytkownika i przekieruj do strony logowania. Ponownie uruchomiliśmy appscan i zostało ponownie zgłoszone, nie jestem pewien jak sobie z tym poradzić.

Kiedy patrzę na raport, pokazuje go włożonego fałszywego referrer, serwer odpowiedział statusem 302, przekierowaniem, a następnie wysłano żądanie logowania, na które serwer odpowiedział 202, podając go. Rozumowanie AppScan mówi:

To samo żądanie zostało wysłane dwa razy w różnych sesjach i otrzymano tę samą odpowiedź. To pokazuje, że żaden z parametrów nie jest dynamiczny (identyfikatory sesji są wysyłane tylko w plikach cookie ) i dlatego aplikacja jest podatna na ten problem.

Ale czy odpowiedź nie zawsze byłaby taka sama? Jeśli kontrola nie powiedzie się, a 302, a następnie 202, pojawi się strona przekierowania i logowania, niezależnie od użytkownika. Czy ktoś wie, jak sobie z tym poradzić? Zgaduję, że mogłem umieścić identyfikator sesji użytkownika w przekierowanym adresie URL, więc appscan zobaczy, czy jest inny, ale pomyślałem, że musi być inny sposób.

To jest aplikacja .net 4. Użytkownicy są śledzeni za pomocą obiektu Session, jeśli to ma znaczenie, Uwierzytelnianie formularzy nie było używane.

Answer 1

Ustaw przycisk użytkownika viewstate, ref: https://security.stackexchange.com/questions/19152/how-does-viewstate-protect-against-csrf To sprawia, że ​​coraz trudniej jest wysłać zapytanie bez konieczności dostępu do obu ostatnich stronę & plików cookie.

Użyj HttpException wrócić 403 (być może trzeba zrobić kilka dodatkowych prac za utrzymanie go przed obracaniem się w 500)

Throwing an HttpException always sends back HTTP 500 error?

i skanuje aplikacja posiada wysoce rozpoznawalny signature-- rzucają 100s wyjątków w tej samej minucie. W ramach infrastruktury rejestrowania błędów możesz chcieć przedstawić captcha po powiedzeniu 5 wyjątków w tej samej minucie lub przedstawić captcha w przypadku błędów, które aplikacja wyrzuca, że ​​twoja aplikacja nigdy nie wyrzuca (jak bardzo długie adresy URL, zapytania do .jsp pliki w aplikacji .aspx). Po zidentyfikowaniu identyfikatora aplikacji chcesz zatruć swoją sesję, zawsze przekierowując na stronę błędu, dopóki nie rozwiąże problemu. Wadą tego jest to, że istnieje niewielka szansa, że ​​użytkownik zostanie zaprezentowany jako capcha po wystąpieniu wyjątku przez aplikację, np. Błąd bezpieczeństwa, gdy użytkownik umieszcza> w polu tekstowym. Możesz lub nie chcesz wdrożyć tę funkcję dla wszystkich skanerów aplikacji, może tylko te złośliwe, zależy od zachęty w Twojej organizacji.