ugrás a tartalomhoz

Saját HTML ($_POST) feldolgozó

Pepita · 2012. Szep. 2. (V), 22.38
Sziasztok!

Támadt egy ötletem, nem tudom, jó-e. Egy korábbi fórumtémában, ahol eredetileg SQL injection volt a kérdés, felmerült a HTML-szűrés (XSS, CSRF szempontból) is, ezzel együtt a HTML Purifier. Ez utóbbival egy pár gondom van:
- Kb. akkora (nagyobb), mint a framework, amit használok (CodeIgniter);
- Számomra annyi lehet (időben) rendesen átlátni, mint írni egy jóval egyszerűbbet;
- Elég nehézkes lenne szerintem ebbe a fw-be jól "bepasszítani" (eddig meg sem próbáltam);
- Kb. 100x annyit tud, mint nekem szükséges.

Ezek miatt úgy gondoltam, írok egyet. (A CodeIgniter-nek nincs sajátja, a Typography Class csak "stilizál", de nem szűri pl. a tag-ek attribútumait.)

Amikre gondolok (szempontok és megvalósítás):
- Kicsi (és gyors) legyen, mint a CI többi része is. Ha végére is érek, ez nem lesz gond.
- Megengedő értékelés, mind a tag-ek, mind attribútumaik terén (itt kérdés: így elég jól lehet XSS-t védeni?).
- Ha egy tag nem megengedett, a benne lévő esetleges szöveg ne vesszen el, hanem pl. kerüljön helyette más tag-pár közé.
- Könnyen konfigurálható legyen (pl. az osztály betöltésekor, mint más CI osztályok).
- Fentiek megvalósítására a PHP DOMDocument osztályát használnám, mégpedig úgy, hogy miközben elemenként olvasom a feldolgozandó HTML-t, ezzel "együtt" egy másik példányban gyártom a másikat.
- Ennek hátránya, hogy terjedelmesebb HTML esetén sok memóriát megehet, de nálam nemigen fordul elő, sőt, 100kB-nyi HTML-nél több szinte sehol. (Ebből a 2 DOM szerintem max. 3-4 megán elfér.)
- Még nem tudom, hogy mennyire működőképes ez az "egyiket olvasom, másikat írom" törtnet, de talán egyszerűbb, mint kibontani tömbbe, aztán gyártani abból az újat. Viszont ezzel meg rekurzív fv. kell, akkor azt meg védeni kell max. hívásszámmal vagy mással.
- A hibás tag-ek javítása nem lényeges, de eltávolításuk igen.

Kérlek írjatok véleményt erről, ha abszolút rossz ötlet, inkább bele sem kezdek. Ha van valakinek biztonsági ill. egyéb (megvalósítási) ötlete/tanácsa, annak is örülnék.

(Én jó ötletnek tartanám az eredményt akár publikálni is, ehhez azért valakinek még ellenőrizni kéne, de ez még messze van.)

Köszi, Pepita
 
1

Helyedben összeállítanék

inf · 2012. Szep. 3. (H), 14.58
Helyedben összeállítanék jogosultság szerinti XSD-ket, és azokkal validáltatnék. Ami nem megy át a rostán azt visszaküldeném. Nyilván előtte elő kéne készíteni a küldött tartalmat (xml-re alakítani), stb... Viszont még mindig gyorsabb és egyszerűbb ez így, mintha te mászkálnál a DOM fán php-vel...

szerk:
Ahogy nézem egy puszta validálás neked nem elég... Nem biztos, hogy ez az XSD-s megoldás annyira egyszerű lenne, mint elsőre gondolná az ember. Űrlaponként erősen változhat, hogy mit fogad el a rendszer... Kevésbé újrafelhasználhatóvá teszi az egészet, ha egy tök más nyelvet berántunk ilyen célra. Nehéz megmondani a validálás eredményéből, hogy pontosan mi nem stimmel. Mondjuk egy olyan űrlapon, ahol vissza kell írni, hogy pl a jelszó legalább 6 karakter kell, hogy legyen, ott meg vagyunk lőve.

Egyébként az első probléma, amibe bele fogsz futni, hogy mi van, ha nem valid html-t küldenek, és nem tudod beparsolni... Most vagy visszaküldöd, hogy nem valid, vagy írsz egy formai validálást és javítást, ami vagy működik, vagy nem...

Én mondjuk kapásból úgy állnék neki, hogy nem megengedő rendszert írnék, és valami olyat, ami kijelzi a hibát is. Pl, hogy nincs jogosultságod onmouseover attribútum használatára, stb...
2

XSLT.

Joó Ádám · 2012. Szep. 3. (H), 22.41
XSLT.
3

Milyen igaz. Nekem

inf · 2012. Szep. 3. (H), 23.44
Milyen igaz. Nekem validálásról alapból xsd jutott eszembe, de transzformálással simán lehet szűrni is... És mivel az XSLT paraméterezhető, ezért akár jogosultság szerint is be lehet állítani, hogy mi az, amit átengedjen, és mi az, amit nem.
4

Symfony2 HttpFoundation Component

virág · 2012. Szep. 4. (K), 10.22
Szia,

nezd meg ezt:

http://symfony.com/doc/current/components/http_foundation/introduction.html#request

nem biztos, hogy jo neked, csak egy otlet :) nem eri meg a spanyolviszt feltalalni... :)
5

Ne tedd.

bamegakapa · 2012. Szep. 4. (K), 13.56
- Nem véletlenül akkora. A HTML-szűrés sokkal trükkösebb, mint gondolná az ember. Eleinte nem úgy tűnik, de ebben az esetben tényleg nem éri meg újra feltalálni a kereket.

- Ha csak egyszerű dolgokra fogod használni, elég gyorsan át lehet látni. A doksik elég jók, tehát később sem lesz gond. Érdemes is megtanulni.

- Google-ben számtalan eredményt ad, ha a Codeigniter és HTML Purifier szavakra keresel. Nem tűnik ördöngősségnek.

- Ha többet tud, az csak jó. Később még lehet szükség lesz rá.
6

Köszönöm a véleményeket

Pepita · 2012. Szep. 4. (K), 16.53
Nem tettem le egészen róla, de előbb át fogom nézni a (linkelt) javaslataitokat.

Biztos, hogy megengedő cuccost akarok, és azért gondoltam a DOM-bejárásra, mert így a bármiféle jogosultsági/attribútum-kérdés kívülről könnyen konfigolható. Pl. a megengedett attr. mehet, többi nem <> ha van benne nem megengedett, egészet visszadobom.

A hibás HTML javítására egyelőre nem készülök (esetleg későbbi verzióban), arra megint csak jó a PHP, hogy errort dobjon, ha hibás (és ezt elkapom). Jelenleg wysiwyg-től származó post miatt gondolkodom rajta, abban (mert jó eszközt használok) csak akkor van HTML hiba, ha a Júzer kézzel írkált HTML-t. Hát ne írkáljon, ha nem tud.

CodeIgniter - HTML Purifier: leírtam mikért nem akarom utóbbit, OK, integrálni nem lehet túl nagy gond, de az, hogy sokan használják, még nem jelenti azt, hogy nekem is az a legjobb. (Ha senki sem csinálna spanyolviaszt, akkor nem lennének ilyen eszközök sem.)
7

Értem én

bamegakapa · 2012. Szep. 4. (K), 22.01
De hiába tiltasz le attríbutumokat (illetve engedélyezel csak bizonyosakat), egy sima href vagy style (stb., stb.) önmagában is rengeteg sebezhetőséget rejthet.

Stackoverflow-n mindenképpen nézz utána, hirtelen például:

- XSS - Which HTML Tags and Attributes can trigger Javascript Events?

- Strict HTML Validation and Filtering in PHP
8

regexp

dropout · 2012. Szep. 4. (K), 23.28
Ahogy végigolvastam a szempontokat, nekem ez ugrott be elsőre. De biztos van oka, hogy nem merült fel, mert egyébként ilyen feladatra teljesen kézenfekvőnek tűnik.
9

Talán ezért.

inf · 2012. Szep. 4. (K), 23.53
10

Véleményes vélemény, de van

dropout · 2012. Szep. 5. (Sze), 10.10
Véleményes vélemény, de van benne valami.
13

HTML is not a regular

Joó Ádám · 2012. Szep. 5. (Sze), 19.03
HTML is not a regular language and hence cannot be parsed by regular expressions.


Ez ténymegállapítás.
11

Nem!

janoszen · 2012. Szep. 5. (Sze), 10.35
Nem parzolunk XML-alapu nyelveket regexppel! Egyszeruen nem tartozik a regularis nyelvek csaladjaba, ergo NEM tudod validalni vele.
12

Ja, én is ezt linkeltem, csak

inf · 2012. Szep. 5. (Sze), 12.40
Ja, én is ezt linkeltem, csak egy kicsit viccesebb formában :D
15

Kizárt

Pepita · 2012. Szep. 7. (P), 16.02
Itt a többiek már elég pontosan leírták, hogy miért, én ezt a lehetőséget eleve kizártam. Védekezésre alkalmatlan. Esetleg hiányzó (záró) tag-ek pótlásánál lehet némi jogosultsága, de itt nem.
14

Ez az.

dropout · 2012. Szep. 5. (Sze), 20.48
Ez az.