Geek úr nyaral

Nem tudom, te hogyan vagy vele, én nagyon aggódós utazásszervező vagyok. Akkor nyugszom meg, ha előre minden le van foglalva, ki van fizetve. Igaz, ekkor meg azon szoktam parázni, hogy időben odaérünk-e mindenhová.

Tudtam, hogy hová akarunk menni a nyáron. Igaz, még január volt, de mivel konkrét eseményre terveztünk, az időpont biztos volt. Maga az esemény miatt jókora tömeg várható, a kiválasztott kemping pedig picike. Ráadásul éppen erős is a forint – ergo minden jel afelé mutat, hogy már most foglaljam le a szállást.

Elmentem a weblapra, megkerestem a Reservation menüpontot.

Nagyítás

Erre feljött egy iframe-be ágyazott webes form. Kitöltöttem az adatokat, rányomtam a ‘send’ gombra. Kaptam egy kövér 404-est.

Nagyítás

Nagyítás

Ez bizony baj. Lemenjek úgy, hogy nincs biztos szállás? Egy ilyen frekventált időpontban?

Akkor már inkább varázsoljunk.

Első lépés: keressük meg, melyik az az oldal, amely végül nem érhető el. Szerencsére a Wireshark mostanában gyakorlatilag bootoláskor indul, így nem okozott gondot a beröffentése. Eljátszottam ugyanezt a foglalást.

Nagyítás

A webes formok adatait az OK gomb megnyomására egy POST paranccsal szokták elküldeni a webes alkalmazás számára. Rakjuk össze a HOST headert és a POST paraméterét: www.veniceincoming/camp/.okmailnew.asp. Ennek az alkalmazásnak kellene átadni a kép alján található szép nagy emaildest változó értékét.
Csakhogy az alkalmazás sztrájkol. Vagy kiment pisilni. Nincs.

Ami elsőre gyanús, az a ‘.’ karakter az URI-ban. Nem szoktak. Írjuk be anélkül az egészet a böngésző címsorába: és rögtön egy alkalmazásoldali hibaüzenetet kapunk.
Első lépésnek jó. Megvan az alkalmazás, a hiba meg jogos, hiszen tényleg nem adtam át semmilyen paramétert.

Nosza.

Alapvetően két stratégia közül választhatunk. Kezdjük az ‘ököllel szöget falbaverős’ technikával.

Megkértem a Wireshark-ot, hogy az elkapott csomagokból rekonstruálja a teljes forgalmat.

GET /camp/auk.asp HTTP/1.1
Host: www.veniceincoming.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.38 Safari/532.0
Referer: http://www.campingsannicolo.com/uk/contattaci-italiano.htm
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: gzip,deflate,sdch
Cookie: ASPSESSIONIDSQRCQASS=CGGHHKLCBAPCGHMGBFPEJFIC
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6,hu;q=0.4
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

Ez volt a kemping weblapjának lekérése.

HTTP/1.1 200 OK
Date: Tue, 19 Jan 2010 18:19:33 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Content-Length: 26933
Content-Type: text/html; Charset=windows-1252
Cache-control: private

<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”>

<html>

Innen jött egy bazi nagy HTML lap. Miért is? Ugye elment egy GET kérés, arra jött egy 200 OK válasz. Nemrég tanultuk, hogy ennek a válasznak a message blokkjában jön vissza a lekért oldal. Mi választja el a message és a header blokkokat? Üres sor. És tényleg.

</body>

</html>

POST /camp/.okmailnew.asp HTTP/1.1
Host: www.veniceincoming.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.38 Safari/532.0
Referer: http://www.veniceincoming.com/camp/auk.asp
Content-Length: 342
Cache-Control: max-age=0
Origin: http://www.veniceincoming.com
Content-Type: application/x-www-form-urlencoded
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: gzip,deflate,sdch
Cookie: ASPSESSIONIDSQRCQASS=CGGHHKLCBAPCGHMGBFPEJFIC
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6,hu;q=0.4
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

emaildest=info%40campingsannicolo.com&cognome=Jozsef&nome=Petrenyi&
email=jpetrenyi%40gmail.com&fax=&mese_arrivo=05&giorno_arrivo=21&anno_arrivo=2010&
totale_notti=3&numero_adulti=4&numero_bambini=&V-TADU=0&V-B2%2F10=0&V-R%2BAUTO=0&
V-CAMP=0&V-TG=0&N-TX2=0&N-TX4=0&N-R4%2F5=1&N-SP=0&N-LAV=0&N-BICI=0&N-ELE=1&
N-PARK=0&N-PARK-M=0&Note=&Submit=Send

Itt történik a lényeg. Először vége van a nagy HTML oldalnak. (Nyilván közben kitöltöttem a mezőket és rányomtam a Send gombra.) A POST paranccsal indul az adatok feltöltése. Egy csomó fejléc mező után jön az üres sor, majd a message blokkban ott figyel az a karakterlánc, melyet a form rakott össze és melyet az alkalmazásnak már jó étvággyal el kellene fogyasztania.

HTTP/1.1 404 Not Found
Content-Length: 1635
Content-Type: text/html
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Tue, 19 Jan 2010 18:20:12 GMT

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01//EN” “http://www.w3.org/TR/html4/strict.dtd”>
<!HTML><!HEAD><!TITLE>The page cannot be found</TITLE>

De nem teszi meg, ehelyett visszajön egy 404-es hibakód. (Emlékszünk, kliens oldali hiba.) Azaz nincs olyan weblap – jelen esetben alkalmazás, melyet meg akartunk hívni.
Az üzenet message blokkjában még ott van egy formázott HTML üzenet is, hogy a nem kockafejűek is értsék, miről is van szó.

Nos, itt van előttünk a teljes folyamat. Minden parancsot, minden fejlécet, minden message blokkot ismerünk. Azt is tudjuk, hogy a POST parancsban van elgépelve az alkalmazás neve.

Mire várunk? Putty.

Nagyítás

Rácsatlakoztam a webszerver 80-as portjára. Soronként átmásoltam a parancsokat a Wireshark kimenetéből. Ahogy egy üres enter-rel jeleztem, hogy vége a parancsnak, rögtön meg is kaptam a weblapot.

Nagyítás

Ha ez most egy böngésző lett volna, akkor értelmezte volna a HTML kódot és szép, színesszagos weblapom lett volna. De most szöveges kliensem van, abban meg így néz ki a weblap.
Képzeletben kitöltöttük a formot, vissza szeretnénk küldeni.

Nagyítás

Vegyük észre, a küldés első sorát, a POST parancsot nem ész nélkül másoltam be. Töröltem a ‘.’ karaktert. A többi maradt. A message blokk utáni üres enter után el is ment a csomag.

Nagyítás

Sajnos kiábrándító eredménnyel. Hiába találtuk meg az alkalmazást, hiába adtunk át neki egy teljesen szabályos adatcsomagot, az alkalmazás hibát dobott. Maximum annyi vigaszt meríthetünk, hogy ez egy 500-as hibakód, azaz kliensként már jók vagyunk, most a szerver dobta el az agyát.

Mondtam, hogy van egy másik módszer is. Egyszerűbb is, elegánsabb is… de kevesebbet lehet belőle tanulni.

Első lépésben lementjük az iframe-ben lévő weboldal forráskódját. Remélem, ezt nem kell külön részleteznem.

Nagyítás

Megkeressük a form parancs action paraméterét. És tényleg, ott van a hibás hivatkozás az alkalmazásra. Kijavítjuk, méghozzá úgy, hogy nem a relatív hivatkozást hagyjuk benne – hiszen a HTML fájl most már itt van a lokális vinyónkon – hanem az abszolút URI-t. Elmentjük, megnyitjuk a böngészőnkben. Kitöltjük a formot, send.
Hiba.

Nagyítás

Ugye látjuk, hogy ez szószerint ugyanaz a hiba, mint amilyet a Puttyban kaptunk – csak itt a böngésző jelenítette meg a szöveget.

A hibaüzenetből egyébként annyit lehet látni, hogy ez egy asp.net alkalmazás, méghozzá a nevéből itélve egy levélküldő alkalmazás. Valószínűleg az lett volna a terv, hogy az alkalmazás emailben elküldi a kempingnek a regisztrációs adataimat – csakhogy a formból rosszul hívják meg, nincs megadva az a cím, ahová a csomagot küldeniük kellene.

Ez ellen már nem segít semmilyen trükközés. Megkerestem a kemping emailcímét és elküldtem nekik szép, ember által is érthető szöveges formában a foglalási igényemet.

– Az írás egy hamarosan megjelenő könyv része. –

4 thoughts on “Geek úr nyaral

  1. Nem asp alkalmazást akartál írni?

    El kell ismerni, nem adtad magad könnyen. 🙂

    Még egy kérdés: ha sikerült volna összehackelni a form küldést, nyugodtan aludtál volna?

  2. Nem asp alkalmazást akartál írni?
    Ezt most hogy érted? Az utolsó putty-os képen láthatod az X-powered-by fejlécmezőben, hogy ez egy asp.net alkalmazás.

    ha sikerült volna összehackelni a form küldést, nyugodtan aludtál volna?
    Mindenképpen. Ugyanis úgy terveztem, hogy a végén azért csak dobok egy emailt is. 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *