Autor Zpráva
bballer
Profil
Začínám se trochu víc hrabat v ochraně webu před injection, XSS apod. A nějak nemohu dohledat nikde na webu nějaké triviální základy.

Ochranu před výpisem, vkladem do databáze nějak chápu. Ale je bezpečné použít jen tak:

if (isset($_GET["logout"])) {
echo "odhlášení";
}

nebo je třeba to zabezpečit? :) Protože když tam nemám zadanou hodnotu a GET je bez hodnoty, tj "index.php?logout", tak mi to nebude fungovat:

$get_logout = htmlspecialchars($sql->real_escape_string($_GET["logout"]), ENT_QUOTES);

if ($get_logout) { echo "odhlášení"; }


Nebo např. mám v $_GET["lang"] == "cs";

Takže jestli musím nějak řešit ochranu když jen kontroluji hodnoty a vypisuji si něco sám. Tj. jestli toto může někdo napadnout:

if (isset($_GET["lang"])) {
if ($_GET["lang"] == "cs") { echo "Česky"; }
elseif ($_GET["lang"] == "de") { echo "Německy"; }
}

Když budu pak vypisovat proměnou, tak jasně vložím to takto:

echo htmlspecialchars($_GET["lang"], ENT_QUOTES);

Takže jestli to moc řeším a takto to stačí, nebo může někdo podstrčit hodnoty i do samotného php kódu a nějak to zneužít?
Keeehi
Profil
real_escape_string se používá, pokud chceš uživatelský vstup použít v sql dotazu. Tyká se toto snad databáze? Vůbec ne => nemá to v kódu co dělat.
htmlspecialchars se používá, pokud chceš vypsat uživatelský vstup v rámci html. Tady už jsi o něco blíže, ale jelikož jím zadanou hodnotu nevypisuješ, nemá to to v kódu co dělat.
XSS bezpečná verze tedy vypadá takto:
if (isset($_GET["logout"])) { 
    echo "odhlášení"; 
}
Ano, je to přesně to, s čím jsi začínal.

bballer:
Takže jestli musím nějak řešit ochranu když jen kontroluji hodnoty a vypisuji si něco sám.
Právě že nemusíš. Tvůj příklad s jazykem je naprosto v pořádku.

Když budu pak vypisovat proměnou, tak jasně vložím to takto
Konečně to začínáš chápat.

Takže jestli to moc řeším a takto to stačí, nebo může někdo podstrčit hodnoty i do samotného php kódu a nějak to zneužít?
V naprosté většině případů to řešit nemusíš. Když ten řetězec jen porovnáváš s jiným, nebo ho nějak modifikuješ, nic ti nehrozí. Jediný problém by byl, pokud bys ho chtěl spouštět. Což se dá provést třeba "funkcí" eval.
eval("  echo 'Foo bar';  ")
Pokud bys tady použil uživatelův vstup, nebezpečné by to bylo.sou i jiné nebezpečné funkce, například call_user_func. Jde však o to, že tyto funkce asi nikdy k ničemu potřebovat nebudeš.
juriad_
Profil *
Ohledně XSS máš pravdu, ale co problém CSRF?

Akce, která má vedlejší efekt musí být odesílaná POSTem. Toto se týká i odhlášení. Po úspěšném zpracování POSTu je nutné přesměrovat.
První zajistí, že na odhlášení nepůjde odkázat, druhé vyřeší problém s historií a refreshem.
Keeehi
Profil
juriad:
První zajistí, že na odhlášení nepůjde odkázat,
Ano, obyčejně odkázat na to nepůjde. Útočníkovi to ale nezabrání odeslat POST požadavek. 1) není problém nastylovat formulář, aby vypadal jako odkaz 2) ani nemusí formulář styovat jako odkaz a čekat, až na něj uživatel klikne, může ho javacriptem sám odeslat, nebo odesílací tlačítko roztáhnout přes celou stránku a nastavit mu vysokou pruhlednost, těch možností je spousta
Obrana proti CSRF není ve změně způsobu odeslání požadavku, ale v tom že klientovi v předchozí odpovědi pošlu nějaký tajný klíč, který on pak přidá do dalšího požadavku a tím ho autorizuje.

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm:

0