Sziasztok!
Azt szeretném megtudni, hogyha egy felhasználó kitölt egy
mezőt, azt PHP-ban mivel kell szűrni, ellenőrizni a mysql_real_escape_string() fg.-n kívül?
Esetleg mutatnátok példát is?
Köszönöm!
- 2338 megtekintés
Hozzászólások
annyira nem értek hozzá, de pl. ez is érdekes lehet számodra
szerk.: vagy ez.
szerk2.: meg találtam neked egy ilyen hosszú, angol nyelvű cikket a témában.
- A hozzászóláshoz be kell jelentkezni
-
- A hozzászóláshoz be kell jelentkezni
ez valami rejtett subscribe?
--
Vajon a BIX-be is van ilyen?
ProLinkek - Linkgyüjtemény
- A hozzászóláshoz be kell jelentkezni
szívesen.
- A hozzászóláshoz be kell jelentkezni
Köszönöm, egyébként:P
--
Vajon a BIX-be is van ilyen?
ProLinkek - Linkgyüjtemény
- A hozzászóláshoz be kell jelentkezni
^^
- A hozzászóláshoz be kell jelentkezni
Tegyünk itt azért egy kis rendet. A basename-nek nem sok köze van a szűréshez, kivéve ha fájlokat kell kezelni, de arra is vannak jobb módszerek. A htmlentities() függvényt főként megjelenítéskor használják. A mysql_real_escape_string()-et pedig tároláskor. Ha csak szűrni akarod az adatokat, akkor a filter_var() függvényt használd, nagyon sok lehetőség van.
- A hozzászóláshoz be kell jelentkezni
Szia!
Használsz valamilyen framework-öt a fejlesztéshez? Ha még nem és nem valami nagyon pici programot/site-ot fejlesztesz én azt javaslom, hogy ismerkedj meg valamelyikkel, nagyon sokat tudnak segíteni az ilyen egyszerű feladatok elvégzésében.
Ott van pl. a Zend. Ingyé' van és tudja, amire szükséged lehet.
Gugli a "zend framework input validation"-re ezt dobja: http://framework.zend.com/manual/en/zend.validate.html
- A hozzászóláshoz be kell jelentkezni
Egy csomó ellenőrzést elvégezhetsz javascripttel is. Persze, nem derült ki, hogy mit akarsz ellenőrizni/szűrni, milyen környezetben...mert weben a javascript sok embernek ki van kapcsolva érthető módon, ott ez nem jó, de intra megoldásnál lehet jó.
- A hozzászóláshoz be kell jelentkezni
Nem vagyok fejleszto de azert laikus fejjel vegiggondolva a kliens oldali validacio biztonsag szempontjabol nem sokat er. Pl. beiktatok egy proxy-t ahol kicserelem a http csomag tartalmat es invalid dolgokat teszek bele. A bongeszom mar elkuldte, tehat a js ezt mar nem tudja validalni.
- A hozzászóláshoz be kell jelentkezni
Ezért írtam, hogy a környezet nem mindegy. Egy intra hálóban te nem iktatsz be semmit, mert repcsi lesz a vége.
- A hozzászóláshoz be kell jelentkezni
Intranetnél is azért jobb a védekezés. Hiába rúgják ki, ha nagy kárt okozott a rendszerben és kiderül hogy ezt azért tehette meg, mert te nem biztonságos alkalmazást készítettél, akkor te is könnyen repülhetsz vele együtt.
- A hozzászóláshoz be kell jelentkezni
Azért intrán nem iktatgatnak be proxyt olyan könnyen....eleve nem konfigolják a gépeket...már ha intranet van és nem hat gép összetolva pistike bt. switch-én.
- A hozzászóláshoz be kell jelentkezni
Proxyt nem, de kártékony input adatot megadhat a felhasználó. Egyrészt kárt okozhat a cégnek (pl. törli az adatbázist vagy a fájlokat), aminek a visszaállítása (ha egyáltalán van mentés) eltarthat egy jó ideig attól függően, hogy van-e előre kidolgozott visszaállítási terv vagy nincs. Másrészt adatot is szerezhet az illető, amivel később visszaélhet.
- A hozzászóláshoz be kell jelentkezni
Oké, elfáradtam.
- A hozzászóláshoz be kell jelentkezni
Oke, en ezt ertem, de a lehetoseg adott, hogy meg repcsi elott beiktassam es invalid inputot kuldjek.
- A hozzászóláshoz be kell jelentkezni
Adott, ha nem nézzük, hogy mit írtam, de akkor kockás papíron is beküldheted.
- A hozzászóláshoz be kell jelentkezni
JavaScriptet inkább használhatóság szempontjából alkalmazzák szűrésre, mivel így nem kell kérést küldeni a szervernek, illetve újratölteni az oldalt, hanem a felhasználóval egyből lehet tudatni, hogy valami rossz (pl. piros keret az inputra). Viszont PHP ellenőrzésre mindenképp szükség van, akár van JavaScript szűrés, akár nincs.
- A hozzászóláshoz be kell jelentkezni
Igaz, ilyen szempontbol elonyos, mert a nem szandekos hibak kezelesenel tehermentesiti a szervert es "szebb", hogy nincs ujratoltes.
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
--
Kliens oldalon max annyit lehet megtenni, hogy figyelmeztesse a felhasználót a weboldal, hogy tényleg így értette-e. Validálni szerveroldalon kell.
--
unix -- több, mint kód. filozófia.
Life is feudal
- A hozzászóláshoz be kell jelentkezni
Nem értünk egyet: a kliensről ha csak lehet, hülyeség ne legyen elküldve. Természetesen a szerver a felküldött adatokat ugyanúgy, vagy akár szigorúbban is(!) ellenőrizze, mint ahogy azt a js-ből a kliensen, hiszen telnettel is lehet adatot küldeni :) - de az, amit megkap, az legyen előszűrve (munkamegosztás rulz)
- A hozzászóláshoz be kell jelentkezni
Alapvetően tökre egyetértünk, csak te azt nem szereted :)
--
unix -- több, mint kód. filozófia.
Life is feudal
- A hozzászóláshoz be kell jelentkezni
Meg lehet oldani, hogy a form csak bekapcsolt/működő JS mellett működjön ;)
- A hozzászóláshoz be kell jelentkezni
Érdemes tartalomra is szűrni (például dátumot vagy email címet tartalmazó mezőnél), erre a reguláris kifejezéseket tudod használni.
- A hozzászóláshoz be kell jelentkezni
+1 mindig is mondtam, hogy nem az az érdekes, hogy POST vagy GET, hanem hogy mi van benne...
Egyébként ökölszabály:
1. ahol felhasználod a stringet, mindig legyen védett. Pl rakd "" közé
2. ha előfordul a stringben az a karakter, amivel véded, azt encodeolni kell.
Elégséges lehet például az addslashes is, környezettől függ. A legtöbb sql sentence parser tokenizál, így a " karakter után mindent egy literálnak vesz a lezáró "-ig. Ha nem tud a user érvényes lezáró karaktert beszúrni (mivel encodeoltad), akkor nem tud kitörni és örülsz.
- A hozzászóláshoz be kell jelentkezni
Érdekes az is, hogy post vagy get, legalábbis ha a funkciójukat nézzük. A get nem változtat(hat)ja meg a szerver állapotát, a post meg igen.
- A hozzászóláshoz be kell jelentkezni
Részletesebben szabad kérni?
--
unix -- több, mint kód. filozófia.
Life is feudal
- A hozzászóláshoz be kell jelentkezni
A RESTet használó alkalmazások például ilyenek.
- A hozzászóláshoz be kell jelentkezni
+1, én sem értem. Miért is? Pl egy listában rákattintva a kuka ikonra általában "...?delete=123" url-re ugranak az oldalak, nincs is értelme a POSTnak, és ugyancsak megváltoztatja a szerver állapotát...
- A hozzászóláshoz be kell jelentkezni
Az rfc szerint a get biztonságos, idempotens metódus, és illene az rfc-t követnie a sok webtákoló péhápépistikének, és nem arra használni, amire pont nem való.
- A hozzászóláshoz be kell jelentkezni
http://thedailywtf.com/Articles/The_Spider_of_Doom.aspx
--
I never let my children watch big band performances on TV. Too much sax and violins. - sickipedia
- A hozzászóláshoz be kell jelentkezni
Na'ongáz... :-P
- A hozzászóláshoz be kell jelentkezni
preg_match input szűrésre jó lesz.
--
unix -- több, mint kód. filozófia.
Life is feudal
- A hozzászóláshoz be kell jelentkezni
érdemes odafigyelni a különböző karakterkódolásokra is!
--
unix -- több, mint kód. filozófia.
Life is feudal
- A hozzászóláshoz be kell jelentkezni
néhány javaslat:
http://wfsz.njszt.hu/projektek_biztonsag.php#data
- A hozzászóláshoz be kell jelentkezni
Köszönöm:)
--
Vajon a BIX-be is van ilyen?
ProLinkek - Linkgyüjtemény
- A hozzászóláshoz be kell jelentkezni
A kliens oldali ellenőrzés és szűrés nem teljes, önmagában nem elegendő! A felhasználó által megadott adatokban SOHA nem szabad megbízni, mivel számos támadásra adhatsz lehetőséget. A PHP 5 ben sok lehetőség van az adatok szűrésére:
Pl:
filter_var()
filter_input()
filter_input_array()
filter_var_array()
strip_tags()
htmlspecialchars()
htmlentities()
stripslashes()
escapeshellcmd()
escapeshellarg()
+ *_real_escape_string, ahol * a használt adatbázis neve, ezeket a kapcsolat létrehozása után tudod használni.
illetve a reguláris kifejezések használata (http://hu.php.net/manual/en/function.preg-filter.php).
- A hozzászóláshoz be kell jelentkezni
subs
- A hozzászóláshoz be kell jelentkezni
szábszkrájb
- A hozzászóláshoz be kell jelentkezni