Paweł Goleń, blog

Sposób obejścia walidacji kodu pocztowego jest prosta. Regexp, który służy do jego sprawdzenia wygląda tak: \d{2}-\d{3}, wystarczy więc dopisać jakiś fragment przed lub po prawidłowym (w sensie tego regexpa) kodzie pocztowym i "walidator" zostanie oszukany. Zresztą tu rozwiązanie podesłał radekk: http://codepad.org/ThxCjqyC?.

Jest to niewątpliwie błąd, nad jego przydatnością można się zastanawiać. Zależy to głównie od tego, co dalej będzie działo się z tak wprowadzonymi danymi. Może to nie mieć żadnego znaczenia (poza wprowadzeniem bzdurnych danych), ale trafiałem na przypadki, w których tego typu błędy prowadziły do naruszenia spójności bazy danych, cała aplikacja przestawała działać i konieczna była ręczna interwencja operatora, który z bazy takie nieprawidłowe dane usuwał.

Sposób obsługi tablic wartości parametru jest cechą specyficzną dla PHP, błąd tego typu występował ostatnio w WordPress (WordPress <= 2.8.3 Remote admin reset password). W przypadku tego przykładu skutki tego błędu są mniej spektakularne. Wyświetlane są komunikaty błędów, które mogą mówić coś o aplikacji (np. jakie wykorzystane są funkcje). Ujawniane jest też istnienie dodatkowego pliku PHP.

Czasami znalezienie czegoś (jakiejś podatności) osłabia czujność/uwagę, co może doprowadzić do przeoczenia innych błędów lub podatności. Niestety, w trakcie testów nie ma informacji ile błędów jest w jakiej formatce, dlatego o przeoczenie błędów wcale nie tak trudno. Niektóre z tych przeoczonych błędów, jak je się już znajdzie, wydają się takie oczywiste...

Jeśli chodzi o XSS, to na razie tylko dwa hinty:

• Wypełnianie formatek może być ZŁE!,
• testowanie parametr po parametrze (każdy parametr z osobna) czasem nie wystarcza,

Powodzenia!