Iš karto nuvilsiu tuos, kurie čia laukia neišsemiamų “copy & paste” kodo aruodų, paruoštų vartojimui. Priešingai - aš pateiksiu savo mintis mainais į jūsų kodo gabaliukus. Nesvarbu ar jūs juos parodysit man ir visai pixel’io bendruomenei, ar laikysite paslėpę savo kietuose diskuose ir slaptuose serveriuose, man daug svarbiau, kad jūs mokėtumėte įgyvendinti idėjas - tai yra pagrindinė programuotojo užduotis, ir pagrindinis pradedančiojo tikslas. Įgyvendinti idėjas. Taigi daug netuščiažodžiausiu, einam prie tikros įžangos ir idėjų.

Pirma mano mintis susipažinus su - nuostabiausia, kas gali būti interneto naršyklėje. Deja, deja… Prieš keletą mėnesių, pradėjus programuoti tinklalapį, kuris reikalauja šiokio tokio saugumo, teko nusivilti. Galvoje sukosi klausimas: iš kur aš žinau, kad siunčiami duomenys yra būtent iš konkretaus kliento? Tikriausiai siūlytumėt naudoti sesijos numerį. Kaskart persiunčiant duomenis siųsti ir jį. Serveryje patikrinus - ar tokia sesija egzistuoja, kažką atlikti arba ne. Tačiau sesijos numeris visada įrašomas naršyklėje kaip kukis (cookie). O aš dėl kažkokių antgamtinių savisaugos instinktų sausainiais visiškai nepasitikiu. Manau, kad jų saugomą informaciją galima be didelio vargo perimti. Taigi vieną vakarą ‘pagooglinęs’ sugalvojau vieną neblogą idėją, kaip padidinti saugumą. Na padidinti bent jau iki tiek, kad blogiukams užimtų daugiau laiko, kol sugebės padaryti kažką blogo. Jei atsibodo skaityti - geriau meskit šitą straipsnį, nes jūsų laukia dar viena įžanga (bet šįkart tikrai paskutinė).

Turbūt tie, kas domisi kompiuteriais ir jų tinklais, žinos, kaip veikia TCP protokolas (ir galbūt supras, kur aš lenkiu), o tiems, kas nežino - štai jums glaustas aprašymas, kaip vyksta susijungimas ir duomenų apsikeitimas TCP protokolu.

  1. Klientas nusiunčia serveriui didelį skaičių vadinamą SYN (Synchronize - prašymas sinchronizuotis).
  2. Serveris gavęs SYN, taip pat sugalvoja dar vieną didelį skaičių, vadinamą ACK (Acknowledge) ir juos abu išsiunčia atgal klientui.
  3. Klientas gavęs šiuos skaičius, ACK vėl išsiunčia atgal serveriui.

Taip įvyksta susijungimas, tolesnis duomenų persiuntimas vyksta panašiu principu, tik kiekvieną kart1 šie siunčiami skaičiai padidinami vienetu, o siuntėjas ir gavėjas žino, kad kiekvienas sekantis SYN ir ACK bus tokio formato “ankstesnisSYN/ACK + 1″. Jei sudominau - skaitykit čia.

Tad galų gale einam prie idėjos. Pradžiai - paprastos. Turėtų užtekti tik vieno skaičiaus. (Tiem, kas ką tik iš dangaus nukrito ar iš žemės išdygo, ar kažkas iš kelmo spyrė - veiksmas vyksta `e per `ą, nebent pasakysiu kitaip). Sakykime, turime du esminius kintamuosius: sequence ir session_id, bei vieną funkciją (kietu pavadinimu): initSecurity(). Jos esmė tokia - užsikrovus puslapiui, pranešti, koks session_id čia kreipiasi ir nori naudotis funkcijomis, kurios turi būti apsaugotos. Serveris įvykdo maždaug tokį php kodą (iškarpa):

sequence =
....
[insert krūva_funkcijų_here]
function kazkokiaFunkcijaSuAjax() {
....
}

Ir atsiunčia, tarkim, tokį tekstą:

sequence = 12345;
...
function kazkokiaFunkcijaSuAjax() {
...
}

Mūsų tikslas - tą tekstą įvykdyti kaip ‘ą, o paskui, kažkur pačiame html kode mes jau galėsime iškviesti funkciją kazkokiaFunkcijaSuAjax(). Bet… kur čia ? tame, kad ta super-duper f-ja, taip pat POST’ina serveriui sequence ir session_id, kuris juos patikrina ir priklausomai nuo teisingumo grąžina reikalingą rezultatą arba kitokį ‘ą:

alert('A kon če dara, ką?');

Tai va, manau bazinį pagrindą čia tekštelėjau. Kas supratot, kas ne - čia nėra saugiausias variantas, tačiau blogiukams vis tiek bus sunkiau konkrečiu momentu sužinoti sequence numerį ir session_id, ir įvykdyti kažkokį kodą kito vardu.

Taip pat idėjos, ką dar būtų galima stebėti, norint padidinti saugumą:

  • Serveryje įrašyti kliento IP (blogiukas turbūt iš kito kompo mėgins laužtis).
  • Pirmam prisijungimui vykstant nusiųsti kai kuriuos lango/ekrano parametrus į serverį.
  • Taip pat galima naudoti ne vieną, o du ir daugiau skaičių su skirtingais kitimo algoritmais.
  • Kai kuriuos saugumą užtikrinančius duomenis - hešuoti.
  • [vieta jūsų žinioms+fantazijai pasireikšti]

Prieštaraujantiems dėl tokio varianto, galiu pareikšti, kad absoliutaus saugumo nėra, tačiau kažkur netoli jo mes visada galime būti.

Panašūs straipsniai


“Ajax - nesaugus, bet ar galima tai pakeisti?” komentarų: 9

  1. Eimantas

    Tai visiškai nėra saugu ir net nėra reikalinga.

    Atliekant “man-in-the-middle” ataką tokius duomenis galima gauti nuo pat sesijos pradžios. O jeigu sesija jau ir yra užmegzta (ne TCP lygyje, o interneto svetainės) - skaičių seką labai lengva atspėti perėmus kelis(/keliolika/keliasdešimt) paketų tiek iš serverio, tiek iš kliento. O tada visas saugumas išgaruoja. Ir tai užimtų tik šiek tiek ilgiau. Tačiau žymiai ilgiau užimti tokio “saugumo” konstravimas.

    Čia taip pat tik pamąstymai. Savo kodo gabaliukus galite slėpti kur tik norite.

  2. Sepa

    Nuo man-in-the-middle atakos, kazhin ar kas ishviso gali apsisaugoti, kai kalba eina apie tokius dalykus.

  3. Martinas

    Iš principo, AJAX kaip toks nėra papildomų klaidų šaltinis, nes tai tėra tik dar vienas transportavimo būdas. Viskas priklauso nuo to, kaip naudosies..
    Plačiau: http://www.whitehatsec.com/home/resources/articles/files/myth_busting_ajax_insecurity.html

  4. pypt

    Saugumui yra SSL’as.

  5. tamole

    Pritariu Martinui. Jeigu nepasitiki per xmlhttprequest perduodamu sesijos id, tai turetum ir nepasitiketi tais, kurie paprastai, be jokiu ajaxu perduodami serveriui… Kad sesijos id perimti galima, tai nieko nuostabaus ar naujo… Tam reikalui galima sesijos ID reguliariai regeneruoti, kad jis nuolat keistusi, taip pat galima neleisti tai paciai sesijai galioti is skirtingu ip, narsykliu ar dar ko nors…

  6. Eimantas

    Pilnai sutinku su Martynu. Ajax tėra technologijų rinkinys. Todėl, manau, iš karto galima pereiti prie duomenų kodavimo serverio pusėje .)

  7. Martinas

    Eimantai, sorry, bet esu Martinas.

  8. Sergej Kurakin

    Visiškai sutinku su Eimantu, Martinu ir tamole.
    Įpač patiko tamoles komentaras, labai gerai pastebeta apie AJAX ir paprastų formų saugumu.

    Įdomu, autorius pasižiurejo ką ir kaip daro kiti tinklapiai saugumo ir AJAX atžvilgių, kurie jau senai ir intensiviai naudoja AJAX?

  9. Nerijus

    “Nuo man-in-the-middle atakos, kazhin ar kas ishviso gali apsisaugoti, kai kalba eina apie tokius dalykus”

    Galima!!! Tam yra SSH, SSL… ir zinoma trusted sertifikatai :)

Rašyti komentarą

Jūs privalote prisijungti jeigu norite rašyti komentarą.