Pár kérdés weblapkészítéssel kapcsolatban?

1. célszerűbb a pdo-t használni, de mindenképpen objektum orientált jellegű függvényeket érdemes használni

2. a bejelentkezés vagy adatküldés védelmét érdemes két lépcsőben megoldani: kliens és szerveroldal. Egyrészt javascripttel is ellenőrizhetőek az adatok, de a szerveroldalon is minden ellenőrizni kell, főleg ha kritikus adatokról beszélünk. A szerveroldali ellenőrzést nem váltja ki az ajax! Adatbázisba írást célszerű előkészített eljárásokkal megoldani (prepared statement).

3. ha csak nem NSA szintű és fontosságú adatokkal bűvészkedsz nem nagyon szabad túlzásba vinni az adatok védelmét. Egyrészt a jelszavakat kódoljuk (hashing) és nem titkosítjuk (crypt). A titkosítás visszafejthető, a kódolás nem. Egy átlagos oldalra bőven elég egy SHA1 kódolás, persze ha félsz hogy feltörik az oldalt, vagy a felhasználók fiókját, akkor egy komolyabb sha256-os hash-t, esetleg valami bcryptes random salt-os kódolást is próbálhatsz, de az egyszerűbb mindig célravezetőbb.

+ a 2. -hoz: limitáld az egység időnyi próbálkozásokat.

Szótározó programmal ne tudják feltörni.

1. Én MySQLi-t használok, hagyományos okokból, de nemrég egy nagyobb lélegzetvétellel írtam egy DB osztály, amit gyakorlatilag ugyanúgy használok, mint a PDO-t, és ha később át akarok állni, már csak kb. 2 helyen kell átírnom.

2. CSFR, ami hirtelen eszembe jut, és szerintem nem triviális még a weben. A dolog lényege, hogy a támadó elérheti, hogy a felhasználó műveleteket hajtson végre egy oldalon a tudtán kívül. Pl. belinkeled itt, hogy [link] - ezzel utalást indítasz a támadónak, ha folyamatosan be vagy jelentkeztetve pl. egy letárolt COOKIE-val. Vagy még aljasabb: a fenti linket egy kép src-jébe teszed be, és még kattintani sem kell.

3. Én SHA256-tal tárolom + valamilyen salt. Igazából az MD5-től már elég sok helyen eltántorítanak, mivel tele van a net szótárakkal. Viszon salt-tal arról sem gondolom, hogy kevésbé biztonságos. Ahogy egy másik válaszoló írta, valahogy korlátozni kell a próbálkozások számát, bár az sem túl egyszerű, hiszen az IP szűrés nem célravezető, minden más meg kikerülhető...

1. A PDO es a MySQLi kozott annyi a kulonbseg, hogy utobbi kicsivel gyorsabb, mivel nativan csak azt tamogatja, mig a PDO bar lassabb, de a DB alatta mindegy, hogy SQLite, MySQL, Postgre vagy MSSQL, konnyen lehet cserelni.

Emiatt szokas a PDO-t javasolni, mert ki tudja, hogy mikor kell DB-t cserelni a rendszer alatt, plusz tesztkod futtatasnal lehet egyszerubb, ha a teszt db csak egy sqlite, mig az eles rendszer alatt egy komplett MySQL cluster fut.

En is PDO-t szoktam inkabb, de attol fugg mi a projekt, legutobb RedBeanPHP-val dolgoztam es imadtam. 1 DB file es sokat egyszerusit a PDO kezelesen is. (De van sok ilyen mas ORM is, az egyik legnagyobb a Doctrine, bar ezt kicsit bonyolultabb tanulni.)

2. Az ORM eseten alap, de PDO es MySQLi eseten meg letfontossagu a prepared statementek hasznalata, ezzel az SQLInjection eleg jol elkerulheto.

A kimenet eseten pedig mindig szurni kell, hogy az XSS-t is elkeruld, plusz hasznos a CSRF vedelem is. Utobbira a neten eleg sok leiras van, hogy hogyan lehet/celszeru.

Az IP alapu rate limit pedig szerintem boven eleg egy form-nal, mivel egy DDoS-t, amugy sem lehet kiveden (meg azt a szerveren kell, nem az appban), ugyanakkor IP-t cserelgetni/proxit valtogatni annyira nem konnyi, nem fog tudni pillanatok alatt senki 10-20k proxit talalni es gyorsan cserelgetni.

3. A jelszo hasheles is mar eleg alap, en inkabb bcrypt-el dolgozom, mivel alapbol kezeli a salt-ot, illetve meg lehet adni az iteracio szamot is, amivel a kesobbiekben meg bonyoluthato a dolog. (Sot, akar meg lehet csinalni, hogy user felhasznalonal 500-at tekersz a hash-en, adminnal meg 1000-et.) Ilyen szempontbol jovot allobbak a parameterezheto hashelesek.