ugrás a tartalomhoz

php biztonság

kriszrap · 2012. Aug. 30. (Cs), 22.01
Sziasztok!!
php biztonságról szeretnék kérdezgetni.
Amit a felhasználó beküld azt lekéne valamivel védenem.
strip_tags(),htmlentities(),htmlspecialchars()
Melyikkel szokták??

és amit kilistázom vagy is a szerverről kapok azt is lekel védeni??
Ha tudtok még valamit ajánlani vagy tippet örömmel fogadom.

Tényleg most jutott eszembe felhasználó jelszót mivel szokták biztonságosan kódolni ?
pl én md5 használok de sztem van jobb.
‹ E-mailt küldő űrlap PHP ›
 ■
1

attól függ

Poetro · 2012. Aug. 30. (Cs), 22.12
Attól függ, mit szeretnél védeni, és mitől. Minden feladat esetén másik függvényt kell használni. MD5 helyett mindenképp legalább SHA1 kellene, és természetesen jelszavakat sózni is illik. Ha nem tudod mi az, nézz utána. Valamint itt is kell legyen cikk a biztonságról PHP szemszögből.
2

ja a sózás plusz karakter

kriszrap · 2012. Aug. 30. (Cs), 23.07
ja a sózás plusz karakter rakunk hozzá és így nem szótározható.
jól tom?
pl felhasználó nevet,emailt adjak hozz?

chat falamba szeretném a karaktereket levédeni.hogy lehetne ?
3

MD5 helyett mindenképp

tgr · 2012. Aug. 30. (Cs), 23.27
MD5 helyett mindenképp legalább SHA1 kellene


Ez a vudu security egy népszerű példánya. Semmilyen lényeges különbség nincs az md5 és a sha1 között biztonsági szempontból (egyik se túl biztonságos, mert gyorsan számolhatók és GPU-n/FPGA-n hatékonyan párhuzamosíthatóak).
8

Kicsi van azért

Pepita · 2012. Aug. 31. (P), 03.31
Azért számolási szempontból az a 4294967296-os szorzó nem elhanyagolható...

Kriszrap, ezt a remek cikkajánlót asszem már linkeltük neked (talán pont én). Kötelező olvasmány haladó szintig. Megtalálod benne a biztonsági kérdésekkel foglalkozó cikkeket is. Utána kérdezz, ha valami még "hibádzik".
12

Milyen 4294967296-os szorzó?

tgr · 2012. Aug. 31. (P), 08.54
Milyen 4294967296-os szorzó?
13

Gyanítom, az SHA1 és MD5

eddig bírtam szó nélkül · 2012. Aug. 31. (P), 09.25
Gyanítom, az SHA1 és MD5 közti 32 bitnyi eltérésre gondolt. :-)
14

Jó, jó, korán volt még... a

tgr · 2012. Aug. 31. (P), 12.18
Jó, jó, korán volt még... a 340282366920938463463374607431768211456 mellett a 4294967296-as szorzó teljesen elhanyagolható.

Konkrétabban, a legmenőbb szuperszámítógépek 10 petaflops (10^16 művelet / sec) körüli teljesítményt tudnak, az durván 10^14 md5 teszt / sec, ami a 10^38 körüli állapotteret figyelembevéve mintegy tízbilliárd évnyi próbálgatást jelent, ha egy ügyes hacker ellopna egyet, és md5-öt akarna bruteforce-olni vele. Mivel mintegy százbillió éven belül kihunynak a csillagok és megfagy minden, nyugodtan kijelenthetjük, hogy ez a támadási modell nem plauzibilis.
15

Google

T.G · 2012. Aug. 31. (P), 13.22
Az egyszerű jelszavaknál a Google is elegendő.
https://github.com/juuso/BozoCrack
És tényleg működik. :)
16

Megfelelő sózással

MadBence · 2012. Aug. 31. (P), 18.55
Megfelelő sózással hatástalanná tehető a módszer. (illetve aki salt nélkül hashel jelszót, az meg is érdemli, hogy a google kiköpje a találatot :D)
4

Amit a felhasználó beküld azt

tgr · 2012. Aug. 30. (Cs), 23.46
Amit a felhasználó beküld azt lekéne valamivel védenem.
strip_tags(),htmlentities(),htmlspecialchars()


Alapelv, hogy a bemeneten szűrsz, a kimeneten eszképelsz. Vagyis ami nem felel meg az elvárásoknak (pl. számot kell megadni, és nem csak 0-9 van benne), azt el sem mented, amit elmentesz, azt pedig nem kódolod át HTML-specifikus formátumra, mert ki tudja, milyen környezetben lesz majd rá szükséged (egész más eszképelés kell, ha HTML forrásban használod, mint ha URL-ben, vagy ha javascripnek akarod átadni).

A htmlentities és a htmlspecialchars között nincs lényeges különbség (szerintem az előbbi teljesen felesleges, csak a kompatibilitást rontja), a strip_tags nem igazán szerencsés, ha pl. ha matematikapéldát szeretne írni a felhasználó, és az a^2 + b^2 < (a+b)^2-nek csak a fele jelenik meg. A htmlspecialchars-nál fontos, hogy jól meg legyen adva a kódolás (és tényleg az legyen a kódolás), és hogy jólformált HTML-t használj.
5

jól formált HTML? Mire

kriszrap · 2012. Aug. 30. (Cs), 23.50
jól formált HTML? Mire gondoltál?
7

Főleg arra, hogy legyenek

tgr · 2012. Aug. 31. (P), 00.07
Főleg arra, hogy legyenek dupla idézőjelek az attribútumok körül. (Btw. ez egy másik ok, ami miatt a strip_tags nem jó ötlet.)
6

Tényleg most jutott eszembe

tgr · 2012. Aug. 31. (P), 00.06
Tényleg most jutott eszembe felhasználó jelszót mivel szokták biztonságosan kódolni ?
pl én md5 használok de sztem van jobb.


Só + bors + valamilyen lassú (work factoros) és biztonságos hashfüggvény, tipikusan bcrypt vagy PBKDF2.
9

Kimaradt...

Pepita · 2012. Aug. 31. (P), 03.38
és amit kilistázom vagy is a szerverről kapok azt is lekel védeni??
Általában nem, mivel be sem engedsz a szerverre olyat, ami nem fasza. De minden inputot megfelelően ellenőrizni és védeni kell. A fv.listához még legalább a mysql_real_escape_string() "jár", mint Poetro is írta: feladat szerint. Az adott funkciók kódolásánál - ha jól sejtem - úgyis lesznek kérdéseid, színezett kód olvasásakor szoktunk szólni, ha durva biztonsági rés van benne. (Akkor is, ha nem azt kérdezed.) De mindenképp olvasd el az erről szóló cikkeket!
10

Na ez így egészen konkrétan

eddig bírtam szó nélkül · 2012. Aug. 31. (P), 06.58
Na ez így egészen konkrétan nem igaz! Szerverre (eddig szinte bárkit kérdeztem, ez volt a reakció), ellenőrzött adatokat engedsz be, de ez nem jelenti azt, hogy pl. törlöd a HTML-be piszkálásra alkalmas kódokat is a bevitt adatokból.
Például egy blog hozzászólásaiban valószínűleg megmaradnak a HTML kódok is, viszont megjelenítéskor mindenképpen konvertálni kell őket (ha jól emlékszem, html_special_chars függvénnyel vagy valami hasonlóval).

De valaki javítson ki, ha tévednék!
11

Igen, inputnál szűrsz,

tgr · 2012. Aug. 31. (P), 08.44
Igen, inputnál szűrsz, outputnál eszképelsz (ebben az értelemben output az is, ha pl. adatbázisba vagy fájlba írsz, minden, amikor az adat elhagyja a PHP-t).
17

Igen, pontatlanul fogalmaztam

Pepita · 2012. Szep. 1. (Szo), 01.37
Én is erre gondoltam, hogy az adatbázisba is (vagy fájlba, ha olyan) már ellenőrzött és megfelelően escapelt adatot rakok (lekérdezésbe szintúgy).
Csak ez már nem input, valóban. A lényeg, hogy a Júzertől jön (jött).
18

A lényeg az, hogy az

tgr · 2012. Szep. 1. (Szo), 11.11
A lényeg az, hogy az eszképelést mindig az utolsó pillanatban és az adott felhasználáshoz igazodva csinálod. Adatbázisba íráskor pl. SQL injection ellen eszképelsz (jó esetben nem kézzel, hanem paraméteres SQL parancsok használatával), de nem eszképelsz XSS ellen, azt csak akkor, amikor a HTML sablonban felhasználod a változót.
19

Én mondjuk jobban szeretem,

MadBence · 2012. Szep. 1. (Szo), 13.09
Én mondjuk jobban szeretem, ha csak a felhasználótól jön nem biztonságos információ, az adatbázisból meg biztonságos. Nyilván ilyenkor elvész az eredeti információ, szóval ha később úgy döntök, hogy jelenjenek meg a html tagek (mondjuk mert megőrülök), akkor nehezebb dolgom van...
20

Bármilyen információ

Joó Ádám · 2012. Szep. 1. (Szo), 14.05
Bármilyen információ hordozhat biztonsági kockázatot, ha nem megfelelően kezeled, nem tudod az adatot egyszerre minden alkalmazási terület számára biztonságos alakban tárolni. Az adatbázis írásakor arra kell ügyelj, hogy az adat ne tartalmazzon érvényes SQL-t, megjelenítéskor, hogy HTML-t sít.

Az az adat, ami biztonságosan megjeleníthető HTML-ként tartalmazhat olyan kódot, ami káros PDF-ben.
21

Minél távolabb van egymástól

tgr · 2012. Szep. 1. (Szo), 17.36
Minél távolabb van egymástól az információ felhasználása és a szanitizálása, annál kisebb az esélye, hogy hiba nélkül át tudod tekinteni, hogy a szanitizálás biztonságos-e. Például egy javascript változónak átadott stringre hiába küldesz strip_tagst vagy htmlspecialcharst, nem véd meg az XSS sebezhetőség ellen, ha email fejlécbe kerül, oda megint egész más védelem kell. Ha minden alkalommal, amikor a fejlesztő fel akar használni egy értéket az adatbázisból, le kell nyomoznia, hogy milyen lehetséges utakon kerülhetett oda és azok hogy vannak védve, akkor elméletben karbantarthatatlan lesz tőle a rendszered, a gyakorlatban meg egyszerűen nem fogja megtenni, és tele lesz a rendszer biztonsági résekkel emiatt.