W dzisiejszym odcinku przedstawię dwie pierwsze zakładki w Burpie. Jest to Target i Proxy. Proxy troszkę “liznęliśmy” w pierwszej części, ale dzisiaj zajmiemy się tym “narzędziem” bardziej wnikliwie.

Proxy – Bramkarz w klubie HTTP

Zakładka Intercept daje nam kontrolę nad aktualnie przechwytywanym Requestem HTTP. To, czy przechwytujemy ruch wskazuje nam przycisk “Intercept is on/off”. Gdy na początku chcemy zapisywać ruch w testowanej aplikacji, ale nie chcemy przeglądać każdego requestu, warto ustawić ten przycisk na Off i spokojnie zrobić rozpoznanie w aplikacji.

Przechwytując Request HTTP w tej zakładce mamy opcje takie jak “Forward”, która służy do przesłania Requestu dalej oraz “Drop”, która służy do zatrzymania requestu i niedostarczenia go do serwera. Przycisk Action pokazuje menu z dostępnymi akcjami na zatrzymanym Requescie, czyli co możemy dalej zrobić z Requestem. Te opcje to m. in. odwzorowanie poszczególnych funkcji w Burpie. Zajmiemy się tym w przyszłych odcinkach.

To samo menu wyświetli nam się po kliknięciu prawym przyciskiem myszy w miejsce, gdzie wyświetlony został Request.

Poniżej przycisków mamy opcję podglądu Requestów.

• Raw pokazuje surowy wygląd requestu, nagłówki i body requestu.

• Params pokazuje jedynie Parametry, które są przesyłane. Może być przydatne, gdy parametrów przesyłanych przez aplikację jest bardzo dużo, a my potrzebujemy czytelnej listy tych parametrów.

• Headers widok nagłówków. Burp pokazuje jedynie informacje o tym jakie nagłówki są wysyłane, a przedstawione jest to w formie tabeli.

• Hex widok requestu w formie szesnastkowej (Hexadecymalnej). Jeżeli ktoś miał do czynienia z HexEditorem, to na pewno się w tym widoku odnajdzie 🙂

HTTP History – Co się tam wydarzyło?

W tej zakładce widzimy całą historię naszych działań w testowanej aplikacji w formie tabeli oraz widok szczegółowy Requestu/Responsu poniżej z opcjami podglądu jak w przypadku zakładki Intercept.

Pola tabeli możemy sortować (osobiście polecam posortować historię tak, żeby najnowsze Requesty pojawiały się na samej górze). W tabeli mamy takie kolumny jak:

• # czyli liczba porządkowa
• Host – informacja o hoście, adresie serwera
• Method –  czyli jaka metoda została wykorzystana w konkretnym Requescie
• URL – dalsza część adresu (np. /login)
• Params – czyli informacja o tym, czy w danym requescie pojawiły się parametry. Jest to istotne z punktu widzenia osoby testującej
• Edited – jeżeli zdarzyło nam się edytować request “w locie” w zakładce Intercept, to taka informacja zostanie odnotowana w tym miejscu. Dodatkowo w podglądzie requestu poniżej pojawią się zakładki Original request i Edited request. Czyli request przed i po zmianach.
• Status jaki serwer zwróci po wykonaniu Requestu.
• Length – wielkość odpowiedzi
• itp

Tuż obok znajduje się zakładka “Websocket History”.  Jest to analogiczny widok historii zapytań, jak w przypadku HTTP History, ale dla Websocketów.  

Options

Proxy Listeners – Tutaj możemy sprecyzować na jakim adresie i na jakim porcie ma działać Burpowe proxy. Niekoniecznie musi to być nasz adres lokalny.  

Opcje : “Intercept Client Request” i “Intercept Server Response” pozwalają na zdefiniowanie reguł, którymi Requesty/Responsy będą przechwytywane w zakładce Intercept. Zauważ, że podczas naszej wstępnej zabawy z Intercept nie przechwyciliśmy ani jednego requestu odnośnie plików graficznych. Na tego typu pliki utworzono regułę, więc reqesty zaczytujące pliki graficzne “nie zaśmiecają” widoku całej komunikacji.

Response Modification. Ta sekcja pozwala na automatyczne modyfikowanie Responsów tak, żeby uzyskać więcej informacji. Nadpisuje HTML, który dociera do przegląrki i pozwala m.in. na wyświetlenie formularzy, które mają na sobie opcę “hidden”. Włącza wyłączone pola, usuwa limit ilości znaków w formularzu lub walidację JavaScriptową

Match and Replace. Kolejna porcja automatyzacji. Możemy stworzyć warunek, w którym określimy, że jeżeli pojawi się w requescie lub responsie fraza XXX, to Burp ma ją zamienić na frazę YYY. To dotyczy całej komunikacji: czy to informacji z nagłówków czy z body requestu. Z listy predefiniowanych warunków możemy np. zasymulować przeglądarkę z IOS czy Androida poprzez zmianę nagłówka User-Agent, ukryć nagłówek Referer czy Ignorować ciasteczka.