terve.
väsäillyt php harjotteita ja nyt hakukenttään tuli ilmeisesti php injektion yritys. hakukenttä/tekstikenttä vastaanottaa seuraavalla tavalla html lomakkeelta:
<form action="haku.php" method="get">
<input type="text" font style="font-size:20px" name="linkki" >
<input type="submit" font style="font-size:20px" value="Lähetä">HAKU.PHP ottaa vastaaan
$income = strip_tags(strtolower($_GET['linkki'])); $fh = fopen("haku.txt", 'a+') or die("Failed to create file"); fwrite($fh, $income) or die("Could not write to file"); fclose($fh); switch($income) { case"oikeasana": include("tulosta.php");break; }
koodia hieman lyhennelty, mutta mitään olennaista en mielestäni ole jättänyt pois.
tuonne (haku.txt) on tullut seuraavanlainen "rimpsu" viisi-kuusi kertaa:
bg5vlm9uzq");print(238947899389478923-34567343546345);//
kysymys onko olenko tuolla strip_tags komennolla turvassa tuollaisilta vaiko en?
kiitoksia jo etukäteen, ja valkeutta odotellen, terveiset porvoosta.
Yleensä teksti kuuluu käsitellä siinä vaiheessa, kun sitä käytetään. Tallennusvaiheessa tehdään vain ne tarkastukset ja muutokset, jotka ovat tarpeen tallentamista varten (tai tiedon hylkäämistä varten). Yleensä strip_tags ei ole hyödyllinen, vaan oikea ratkaisu voi olla esimerkiksi tulostusvaiheessa htmlspecialchars. Riippuu tietenkin tavoitteesta.
Nykyisen koodin mahdolliset ongelmat riippuvat siitä, minne $income-muuttuja ja haku.txt päätyvät lopulta.
Jos teksti ajetaan PHP-koodina eval-funktiolla tai komentorivikomentona esimerkiksi shell_exec-funktiolla, tilanne on tietenkin äärimmäisen paha ja sivustosi voi olla jo täynnä viruksia.
Jos teksti ajetaan PHP-koodina includella, ongelmaa ei ole, koska myös PHP-tagit on poistettu. Toisaalta tässä pätevät muut HTML-sivua koskevat ongelmat.
Jos teksti lisätään tuossa muodossa SQL-kyselyyn, hakkeri voi todennäköisesti lukea ja ehkä jopa muokata tietokantaasi.
Jos teksti lisätään jonkin tagin sisään (esim. <a href=$teksti>) tai script-tagien väliin (<script>$teksti</script>), teksti voi sisältää JavaScript-koodia tai muuten haitallisen nettiosoitteen, ja sivun käyttäjien tiedot ovat vaarassa.
Jos teksti tulostetaan muualle HTML-sivulle (esim. <p>$teksti</p>), tagien poisto periaatteessa riittää käsittelyksi, mutta &-merkinnät kuten & käsitellään edelleen HTML-koodina eli tulos ei välttämättä ole toivottu.
Metabolix kirjoitti:
Yleensä teksti kuuluu käsitellä siinä vaiheessa, kun sitä käytetään. Tallennusvaiheessa tehdään vain ne tarkastukset ja muutokset, jotka ovat tarpeen tallentamista varten (tai tiedon hylkäämistä varten).
Olen kyllä eri mieltä asiasta. Jos lomakkeella on tekstikenttä ja rikastekstieditori, joka sallii vain osan HTML-tageista, niin backendin puolella on teksti vielä joko validoitava tai filtteröitävä niin, että jos käyttäjä yrittää häxäämällä syöttää blacklistillä olevia tageja, niin ne karsitaan pois. Missään nimessä suotimatonta syötettä ei pidä tallentaa kantaan.
Strip_tags on kuitenkin täysin väärä lähestymistapa, olipa tarkoitus sallia HTML tai kieltää se kokonaan. Kyllä normaaliin tekstiin pitää voida kirjoittaa <body> vaikkei HTML:ää olisikaan sallittu. (Ja jos on sallittu, niin silti pitää voida kirjoittaa "<body>" niin, että se tulee ruudulle tuollaisena tekstinä eikä upotu sivun HTML:ään elementtinä.)
The Alchemist kirjoitti:
Metabolix kirjoitti:
Yleensä teksti kuuluu käsitellä siinä vaiheessa, kun sitä käytetään. Tallennusvaiheessa tehdään vain ne tarkastukset ja muutokset, jotka ovat tarpeen tallentamista varten (tai tiedon hylkäämistä varten).
Olen kyllä eri mieltä asiasta. Jos lomakkeella on tekstikenttä ja rikastekstieditori, joka sallii vain osan HTML-tageista, niin backendin puolella on teksti vielä joko validoitava tai filtteröitävä – –
On melko vaikea nähdä ristiriitaa näissä katkelmissa, mutta ilmeisesti sellainen silti yrittämällä löytyy. Jos on tarkoitus tallentaa rajoitettua HTML-koodia, tietenkin silloin ”tarkastukset ja muutokset, jotka ovat tarpeen tallentamista varten” voi tarkoittaa validointia tai filtteröintiä. Se ei myöskään poista tarvetta oikealle käsittelylle tulostusvaiheessa, esimerkiksi jos jokin rajapinta palauttaa kyseisen koodin JSON-muodossa tai koodi pitää saada tekstikenttään muokattavaksi.
kiitoksia.
Metabolix kirjoitti:
Nykyisen koodin mahdolliset ongelmat riippuvat siitä, minne $income-muuttuja ja haku.txt päätyvät lopulta.
tuossa tekee vain tuon ja pitää listaa siitä mitä minulle kirjoitellaan.
lähdetään siitä ettei ne joudu kovinkaan kummoiseen käsittelyyn jatkossakaan, perus teksti funkitoihin ja taulukoihin muuttujat ja .txt , niitä mitä php haasteessa ekassa kolmessa kymmenessä. (kiitos muuten siitä upea asia)
vähän nyt vielä olen pimennossa olenko nyt turvassa vaiko pitääkö minun huolestua, tulkitsen ettei mitään ihmeempää vaaraa ole.
Aihe on jo aika vanha, joten et voi enää vastata siihen.