ugrás a tartalomhoz

SQL Injection védése keresés esetén

haho · 2012. Jún. 23. (Szo), 15.51
Sziasztok!
Fórum üzenet írásakor az adatbázisba feltöltendő kódot a htmlentities($keresettKifejezes,ENT_QUOTES,"UTF-8") és a mysqli_real_escape_string() függvényekkel kódoltam. Ez eddig oké. Jól működik.

De keresés esetén (SELECT * FROM filmek WHERE filmCimek LIKE '%$keresettKifejezes%') olyan gondot okoz, hogy az escape-elt írásjelek miatt nem kapok megfelelő találatot.
Pl. ha egy film címben szerepel az aposztróf (valami'filmcím) akkor ugyanez a keresett kifejezés ez lesz "valami\'filmcím" ugye és ezért nem kapok megfelelő találatot.

Nem tudom mi lenne a megoldás. Hogyan kell ilyenkor eljárni? Köszi!
‹ contact form subject kérdés POST adat küldése HTTPS-nek, hogyan? ›
 ■
1

Hogyan kell ilyenkor

kuka · 2012. Jún. 23. (Szo), 16.00
Hogyan kell ilyenkor eljárni?
Vagy Disabling Magic Quotes alapján kikapcsolod a magic_quotes_gpc-t, vagy frissítesz PHP 5.4 verzióra.

Ami a htmlentities() használatát illeti, azt csak megjelenítés előtt kellene alkalmazni, nem adatbázisba írás előtt.
2

Nem igazán értem, hogy mi a

inf · 2012. Jún. 23. (Szo), 16.05
Nem igazán értem, hogy mi a gondod. Ha a az adatot escapeled, akkor a keresőkifejezést is escapelni kell.
SELECT * FROM filmek WHERE filmCimek LIKE '%$keresettKifejezes%'

Egy ilyenért meg eltörik a kezed jobb helyeken...

Az SQL injection védéséről tényleg tanulnod kell még, mert a htmlentities az XSS-re lenne jó, de a htmlspecialchars-t kellene használnod arra is helyette, mert az működik, ez meg nem.
3

Mire gondoltál

haho · 2012. Jún. 23. (Szo), 16.15
"Egy ilyenért meg eltörik a kezed jobb helyeken.." - ez elég kedves megfogalmazás volt tőled. De mire gondoltál? Ezt arra írtad, h a htmlentities függvényt használom. Vagy melyik hibára?
5

Ez nem megfogalmazás volt,

inf · 2012. Jún. 23. (Szo), 16.35
Ez nem megfogalmazás volt, hanem szállóige, sokan használják ebben a szakmában...
Arra, hogy nincs SQL escape $keresettKifejezes-en, így lazán injektálható. Használj PDO templateket.
4

Bind

eddig bírtam szó nélkül · 2012. Jún. 23. (Szo), 16.23
Nézd meg, mi az a bind (mysqli vagy PDO kell hozzá, ha jól tudom, a régi, immár "unsupported" mysql driverrel nem működik)
Ha ilyet használsz, akkor nincs szükség a bemenő adatok escape-elésére amennyire tudom.
6

Érdemes htmlspecialchars-t

inf · 2012. Jún. 23. (Szo), 16.36
Érdemes htmlspecialchars-t ráereszteni, különben html-t is injektálhatnak.
7

input?

eddig bírtam szó nélkül · 2012. Jún. 23. (Szo), 16.50
Befelé kit zavar? ;-)
9

Engem igen, bár igazatok van

inf · 2012. Jún. 23. (Szo), 18.43
Engem igen, bár igazatok van abban, hogy jobb lenne csak kifele escapelni, mert nem biztos, hogy html-ben jelenítem meg. A kifelével az a baj, hogy akkor meg elfelejtem... :-)
12

wysiwyg

Pepita · 2012. Jún. 24. (V), 01.33
És mi van, ha a hózzászólás írása is wysiwyg?
Akkor maradt a strip_tags és nemkevés ügyeskedés a js ellen...
13

Hát ha html-t kapnék, akkor

inf · 2012. Jún. 24. (V), 04.45
Hát ha html-t kapnék, akkor biztos, hogy xsl-t eresztenék rá.
14

Viszonylag kevés értelme van

tgr · 2012. Jún. 24. (V), 06.28
Viszonylag kevés értelme van wysiwyg szerkesztőt használni csak azért, hogy utána strip_tagsszal újra plaintextet csinálj belőle. Ügyeskedés helyett, ami garantált kudarc (pl. kiszúrná-e a szűrőd azt a script taget, aminek minden betűje után van egy \x0 bájt?) célszerű valamilyen professzionális HTML-szűrő eszközt használni, pl. HTML Purifier.
15

Ebben biztos vagy?

eddig bírtam szó nélkül · 2012. Jún. 24. (V), 08.05
Ügyeskedés helyett mindig jobb a járt utat választani, eben egyetértek, de az a \x00 bájtos trükk van ahol működik?

<?php
$str="<script>alert('hello');</script>";
for($i=0; $i<strlen($str); $i++){
        echo substr($str,$i,1).chr(0);
}
Ha kiveszem belőle a .chr(0)-t, akkor végrehajtódik a script. Ha benne hagyom, akkor egyszerűen megjelenik a forráskódja. (FF13 linux alatt)
16

IE7-re van, de vannak hasonló

tgr · 2012. Jún. 24. (V), 10.42
IE7-re van, de vannak hasonló trükkök bőven a legkülönbözőbb böngészőkre:
http://ha.ckers.org/xss.html
http://html5sec.org/
17

Pontosítok

Pepita · 2012. Jún. 25. (H), 01.17
A strip_tags-nek ugye meg tudom adni a megengedett tag-eket. Ezt HTML szűrésre használom, mert pl. képeket nem akarok megengedni, de "minden mást" igen.
Ügyeskedés helyett, ami garantált kudarc
Ezt vitatnám. Miért lenne igaz az, hogy "jó szűrőt csak mások tudnak írni, én nem"?! Tudom, az általad profi szűrőnek hívott Purifiert sem egy ember fejlesztette (és pláne nem egy nap alatt), viszont az ilyen széles körben ismert szűrőket gyakran is kell frissíteni. A hackerek mindig találnak ki újakat, és ők is ismerik ezeket a szűrőket. Az egyedit pedig nem.

De ha már így terítékre került, megnézek párat. Legjobb lenne vmi olyan (egyszerű) wysiwyg eszközt gyártani, ami nem HTML-t, hanem pl. valami bbcode-félét ad vissza a szervernek, akkor a maradékra mehetne a jó öreg htmlspecialchars, oszt jónapot.
18

Ezt vitatnám. Miért lenne

inf · 2012. Jún. 25. (H), 03.32
Ezt vitatnám. Miért lenne igaz az, hogy "jó szűrőt csak mások tudnak írni, én nem"?! Tudom, az általad profi szűrőnek hívott Purifiert sem egy ember fejlesztette (és pláne nem egy nap alatt), viszont az ilyen széles körben ismert szűrőket gyakran is kell frissíteni. A hackerek mindig találnak ki újakat, és ők is ismerik ezeket a szűrőket. Az egyedit pedig nem.


Ez kivételesen olyan helyzet, ahol a nyílt forrású kód nagyon előnyös. Ha valaki talál benne egy kiskaput, akkor tud szólni azonnal. Az ilyen kódok egy rakat know how-t gyűjtenek össze, amit neked meg kell szerezni egy egyedi szűrőnél, hogy hasonló szintűt tudj alkotni. Hacsak nem hobbiból csinálod, ennek nem sok értelme van, mert egy csomó feleslegesen ráfordított idő és energia...

A strip tags nem utf-8as fgv, úgyhogy felejtős.
19

OK, köszi.

Pepita · 2012. Jún. 25. (H), 04.02
Igen, igazad van, csak én eléggé olyan beállítottságú vagyok, hogy "mire szól valaki" (akár én), már lehet, hogy az én honlapom támadták meg. Persze mindent kivédeni lehetetlen, de bennem van egy elég erős ellenérzés a mások által fejlesztett dolgok megbízhatóságát illetően. Nincs igazam, ezért teszek is néha kivételt, de valahogy akkor sem szeretem...
A strip tags nem utf-8as fgv, úgyhogy felejtős.

Nem éppen:
Changelog
5.0.0 strip_tags() is now binary safe

Nem kell feltétlenül mb_... fv-nek lennie ahhoz, hogy helyesen adja vissza az ékezetes, stb. maradékot. Eddig nem volt vele problémám, pedig számtalan helyen használtam, ahol még a default_charset is utf-8 volt (és minden más is persze).
20

Hmm, én csak abból gondoltam,

inf · 2012. Jún. 25. (H), 04.31
Hmm, én csak abból gondoltam, hogy nem lehet megadni karakterkészletet neki. Bár ha tényleg csak a <> karakterekre keres rá, akkor azoknak gondolom elég fix a kódja, tehát tényleg elképzelhető lehet, hogy alapból minden kódolás mellett működik.

Hát ha jól átgondolod, hogy pontosan mire van szükséged, akkor legtöbbször találsz hozzá eszközt. Én meg szoktam nézni, hogy ennek az eszköznek milyen a kódja, aztán a kód minőségéből levonom a következtetést, hogy akarom e használni. (Mondjuk ez általában nálam is nem. :-) ) A purifier-rel az a helyzet, hogy elég jól meghatározott célja van, és sokan ajánlják, tehát nagyon nagy valószínűséggel jól látja el a feladatát. Egy keretrendszert pl sokkal nehezebb lenne így megítélni...
21

Ad 1. ha úgy állsz hozzá,

tgr · 2012. Jún. 25. (H), 09.27
Ad 1. ha úgy állsz hozzá, hogy "X taget nem engedem, a többit igen", akkor máris vesztettél. (Pl. tudtad-e, hogy a legtöbb böngészőben le lehet zárni a body-t, nyitni egy új head-et és izgalmas dolgokat írni bele? Tudod-e, pontosan milyen új tagek vannak HTML5-ben? Tudod-e, melyik böngésző milyen nem szabványos tageket kezel, és mit csinálnak azok?) Szerencsére a strip_tags okosabb, és eleve nem is kínál fel ilyen lehetőséget, csak fehérlistát. (Általában, bármilyen komolyan vehető biztonságtechnikai eszköz fehérlistával működik, nem feketelistával. Feketelista esetén egyrészt azonnal sebezhetővé válsz, ha megjelenik valami új dolog, amiről eddig nem tudtál, másrészt a parser lesz a leggyengébb láncszem, hogy pl. felismeri-e, hogy a <scri<!---->pt> vagy a <scri\0pt> az egy script tag.)

Ad 2. ha csak azzal foglalkozol, hogy milyen tagek lehetnek, máris vesztettél. Bármilyen tag alkalmas XSS-re - pl. az onmouseover vagy a style attribútumból tudsz javascriptet futtatni (és akkor a HTML5 felturbózott eseménykezeléséről még nem is beszéltünk).

Ad 3. az a különbség a biztonságtechnika és a legtöbb egyéb terület között, hogy elsőre kell jól csinálni. (Ugye ha elszúrod az SQL optimalizációt, azt onnan veszed észre, hogy lassú a rendszer; ha elszúrod az SQL escape-elést, azt onnan veszed észre, hogy elkezdik az ügyfeleid bankkártyaszámait árulni Ukrajnában. Mire kiderül, hogy egy biztonsági szűrő nem működik, már régen késő.) Tehát jó szűrő az, amit mások már megírtak, és hosszú ideje használnak, és még nem törték fel. (És ugye itt is igaz az, ami a kriptopgráfiában, hogy bárki tud olyan szűrőt írni, amit ő maga nem tud feltörni...)

Ad 4. a komoly szűrők úgy működnek, hogy beparsolják a HTML forrást, felépítenek belőle egy DOM fát, eldobnak mindent, ami nincs fehérlistán, standardizálják a kódolást, aztán a DOM fából új HTML forrást generálnak (ami garantáltan valid, és ezért pontosan tudható, hogy kezelik a böngészők, szemben azzal, ha megengedsz invalid kódot, és azzal is trükközhet a támadó). Egy ilyet megírni nem gyerekjáték; még ha sikerül is (amit kétlek) és biztonságos is lesz (amit még jobban kétlek), rengeteg időd megy el rá, teljesen feleslegesen. Használd a létező eszközöket, azért vanak.
22

+1

inf · 2012. Jún. 25. (H), 09.36
+1
25

Köszönöm a sok infót,

Pepita · 2012. Júl. 3. (K), 00.34
elnézést, hogy csak most reagálok.

1.: Nem, én csak megengedett tag-eket engednék, tehát fehérlista, és pont ezért "barátom" a strip_tags.

2.: Igen, emiatt gondoltam valami bbcode-félére, de wysiwyg, mert a felhasználóbarátság... Nyilván ez nem egyszerű feladat, legalábbis még nem láttam ilyen szerkesztőt.

3.: Pont ezt írtam fentebb, hogy ezért nemigazán bízok a mások fejlesztésében - és abban, amit sokan használnak -, mert ha egyszer feltörik, akkor későn fogok tudni róla. Nyilván az, hogy "hosszú ideje használnak, és még nem törték fel" már jóval többet jelent. (A zárójel nagyon tetszik :))

4: Épp most csináltam egy nagyon egyszerű DOM-parsert, mert nem akartam egy, többnyire évente egyszer változó lap kedvéért külön adattáblát csinálni, az egész tartalom egy cím és egy nem-tudjuk-hány-elemű definíciós lista. Jól meg is szi****am vele magam, hogy lehessen még benne <em>, <q> és még mindig nem az igazi. És ennél még nem is kell XSS filter sem...

Tehát igencsak megfontolom amiket írtál, amint időm engedi, Purifier-tanuló leszek. Remélem, ez kevesebb idő.
23

Legjobb lenne vmi olyan

tgr · 2012. Jún. 25. (H), 09.37
Legjobb lenne vmi olyan (egyszerű) wysiwyg eszközt gyártani, ami nem HTML-t, hanem pl. valami bbcode-félét ad vissza a szervernek, akkor a maradékra mehetne a jó öreg htmlspecialchars, oszt jónapot.


Ha lehetőséged van rá (nem kell pl. a biztonságos HTML attribútomok használatát engedni), akkor messze ez a legjobb megoldás (a bbcode nem túl felhasználóbarát, de pl. markdownnal szép is lesz, könnyen kezelhető is lesz, meg jó wysiwyg eszközök is vannak rá.) A HTML szűrők olyan esetekre kellenek, amikor pl. engedni akarod, hogy a user CSS szabályokat használjon (és jól szétbarmolja az oldal designját).
24

Én bbcode helyett inkább

inf · 2012. Jún. 25. (H), 10.24
Én bbcode helyett inkább XML-t ajánlanék... Ha leformázod, akkor a nem engedélyezett tag-eket úgyis kiszórja a rendszer... Mondjuk amiben problémásabb, hogyha nem valid xml, akkor nem parsolja be, de egy editorral elég könnyen generálható valid XML, akár még úgy is, hogy kliens oldalon is dom xml objecttel hozod létre.
26

Egyre tudatlanabbnak érzem magam!

Pepita · 2012. Júl. 3. (K), 01.01
Tudom, ez normális, de én nehezen viselem.
A bbcode-ot nem hagyományos értelemben gondoltam, hanem azt is vmi kliensoldali wysiwyg-el.
Eddig én nem láttam - igaz, nem is nagyon kerestem - markdown-wysiwyg eszközt, van ami tényleg jó? (Nálam a jó kicsi, könnyen kezelhető/beállítható, böngészőfüggetlen, nem kell sokat tudjon, úgyis kikapcsolok rajta sokmindent.)

Egyelőre - hála Istennek - semmi CSS-t nem kell engedjek (nem is szeretnék soha), viszont az jó lehet, ha pl. osztályattribútummal ellátott bekezdések/címek/stb közül is választhat a Júzer. De ennél fontosabb a kis erőforrásigény, láttam már nemíromidemelyik wysiwyg-től behalt FF-t és IE-t is. Persze a vas(ak) is "könnyű" volt.
27

Bocs, a wysiwyg-en

tgr · 2012. Júl. 4. (Sze), 01.07
Bocs, a wysiwyg-en átsiklottam mentálisan... nem wysiwygben a wmd szerintem elég profi (ezt használja pl. a stackoverflow).
29

A wmd már nem létezik,

inf · 2012. Júl. 5. (Cs), 15.16
A wmd már nem létezik, legalábbis nem tudtam letölteni a linkedről, és azt olvastam sto-n, hogy átnevezték pageDown és markDown editorra. Elvileg a pageDown a kliensen futó js, a markDown meg cSharp-ban írt valami szerver oldalra, gondolom ami képes kezelni, átalakítani a klienstől jövő kéréseket.
30

Én sem tudtam

Pepita · 2012. Júl. 6. (P), 00.18
letölteni, de gugliztam másikakat, csak még nem volt időm rendesen átnézni őket. Elsőre úgy tűnik, a feldolgozót nekem kell majd prezentálnom, talán olyan is van, amiben van minta.
31

Ez még friss, de nagyon

tgr · 2012. Júl. 20. (P), 22.42
Ez még friss, de nagyon impresszív: hallojs
32

IE8 hallo :)

Pepita · 2012. Júl. 21. (Szo), 04.57
IE8 helló, a demóoldalon 7 js, maga az editor így hiába ~70 kB. Nálam már bukott is - egyelőre.
33

Magyarul?

Poetro · 2012. Júl. 21. (Szo), 09.17
Ezt most leírnád egy magyar mondatban? Mert én nem értettem meg, mit szerettél volna írni.
34

bip-bip bocsika!

Pepita · 2012. Júl. 21. (Szo), 23.26
Egyben nem tudom, de kb. azt jelenti:
- a demóoldalon IE8 alatt nem működött;
- maga a szerkesztő 70 kB, de viszonylag új jquery-ket igényel (az én igényeimet eddig kielégítette az 1.4 is);
- bár a kódot nem nyálaztam át, de a demóoldalon sok egyéb js is van.

Korábban írtam ezzel kapcsolatban, hogy nekem a kis méret is szempont. A sok (darab) járulékos js-ből, és az újabb jqueryből arra következtetek, hogy összességében "nem elég kicsi". És nálam nagyon-nagyon nagy hátrány az IE8 hiánya is (adott esetben kizáró ok).

Én leginkább olyan eszköznek örülnék, ami "tényleg wysiwyg" (= nem markdown kódokkal formázol, hanem gombokkal), de a szerver felé markdown-t küld; elég neki jquery 1.4 (még jobb, ha nem kell hozzá); és max 70 kB. Lehet, hogy ilyen nincs is, túl álmodozó vagyok. De ha találnék, akkor ezt az egyet használnám.
35

Ha a gyökerénél fogod meg a

deejayy · 2012. Júl. 23. (H), 07.52
Ha a gyökerénél fogod meg a problémát, akkor szerintem a végkövetkeztetés egy html->markdown konverter lesz: http://domchristie.github.com/to-markdown/
28

lol

blacksonic · 2012. Júl. 4. (Sze), 11.44
Egy ilyenért meg eltörik a kezed jobb helyeken..

hamar leirtad hadd idezzelek teged :)
8

Megértettem!

haho · 2012. Jún. 23. (Szo), 17.59
Köszi emberek! Meg is csináltam.

Tehát htmlspecialchars-t használtam ott ahol meg akarom jeleníteni az eredményt (pl. komment üzenetek),
és mysqli_real_escape_string-el ott kódoltam csak ahol az adattal az adatbázisműveletet végzek.

És hát ez is volt a baj tényleg amit mondtatok, hogy a htmlentities-t egyáltalán használtam adatbázis művelethez. Most már a keresőm is jól megy.
10

Ez a könyv

joed · 2012. Jún. 23. (Szo), 22.03
Ez a könyv szerintem hasznos olvasmány lenne számodra: Biztonságos webalkalmazások PHP nyelven
11

Már majdnem megvan

haho · 2012. Jún. 23. (Szo), 22.26
Köszi az ajánlást!
Már rá is tettem egy példányra a kezem a neten. Minden bizonnyal napokon belül el is fogom olvasni.