Od czasu do czasu w trakcie testów aplikacji można spotkać się z sytuacją, gdy aplikacja nie działa prawidłowo po skonfigurowaniu proxy (np. Burp). Dotyczy to często "grubych klientów", które wykorzystywane są do tradingu. Dlaczego tak się dzieje?
Gdy aplikacja nie działa przez proxy
Dwie sprawy:
- Proxy, przynajmniej te wykorzystywane przy testach, buforują odpowiedź serwera;
- Wspomniane aplikacje potrzebują ciągłej informacji o kwotowaniach (np. aktualne kursy walut);
Technicznie kwotowania często są realizowane w taki sposób, że klient łączy się z serwerem wykorzystując HTTP, a serwer odpowiada niekończącym się strumieniem danych. W takim przypadku proxy próbuje tę odpowiedź zbuforować, a klient czeka w nieskończoność na odpowiedź serwera.
Jak szybko sprawdzić, czy niedziałanie aplikacji wiąże się właśnie z tym scenariuszem? Moim zdaniem najłatwiej do tego jest użyć Fiddlera i włączyć opcję "Stream". Dzięki tej opcji Fiddler zacznie przesyłać odpowiedź od serwera natychmiast po tym, jak serwer zacznie odpowiadać, nie będzie buforował odpowiedzi. Jeśli po włączeniu tej opcji aplikacja zaczyna działać, wiadomo co jest problemem.
Niestety, ten tryb nie do końca nadaje się do testowania, w szczególności z oczywistych powodów nie działa modyfikacja danych przesyłanych z serwera do klienta. Tryb ten można jednak selektywnie włączyć na poziomie konkretnej sesji spełniającej określone warunki - wystarczy prosty skrypt robiący coś takiego:
oSession.bBufferResponse = false; oSession["log-drop-response-body"] = "yes";
Więcej:
Fiddler doskonale nadaje się również do identyfikacji, które z requestów powinny zostać wyłączone z buforowania, a to dzięki temu, że wyświetlana ikona sesji (patrz: The Web Sessions List) informuje o jej stanie i łatwo jest zobaczyć, które z sesji są tymi "niekończącymi się".
No dobrze, a Burp? Burp również posiada analogiczną funkcję - patrz: Suite Options: HTTP, sekcja "Streaming Responses". Ta opcja również działa (bo czemu by miała nie działać), przy czym z wykorzystaniem samego Burpa ustalenie, które URLe powinny być streamowane może być cięższe, przynajmniej moim zdaniem.
W OWASP ZAP można zastosować nieco inne podejście - wykluczyć określone URLe z proxy - patrz: Session Properties dialog.
