htmlspecialchars and addslashes vs stripslashes

[webdeveloper]

Здравейте, ще помоля за малко мнения по темата. Как е по-удачно да си защитавам входните данни с htmlspecialchars(addslashes(..)) или със stripslashes?

Направи ми впечатление, че когато ползвам htmlspecialchars и addslashes в комбинация, addslashes нещо май не сработва, защото ако подам заявка към базата от типа на:

<?php echo 'sad'; ?> не слага обратни наклонени черти пред кавичките, а би трябвало, все пак нали това е неговата задача? Може би това е проблем на уеб сървъра ми, но както и да е. stripslashes пък, изобщо не прави запис в базата данни ако има такива "атакуващи" заявки, което май е по-добрият вариант?

mysql_real_escape_string пък директно пуска заявката да си щъка из базата данни без никакви промени.

 

[stan4o]

$ne6to = htmlspecialchars(addslashes($_POST['ne6to']));

Така :?
или така ?
$ne6to = htmlspecialchars(mysql_real_escape_string(strip_tags($_POST['username'])));

 

[tedo96]

Аз го правя с:

$ne6to = htmlspecialchars(addslashes($_POST['ne6to']));

 

[stonybg]

аз лично ползвам тази функция

    function strip_slashes($value) {
	    $value = stripslashes($value);
	    $value = str_replace("/", "[fw$]", $value);
	    $value = str_replace(".", "[fw$]", $value);
	    $value = strip_tags($value);
	    return $value;
    }

като заменям проблемните символи с уникален таг който после мога да го обърна в подходящ знак при извеждането на информацията

 

[webdeveloper]

Както и да е, явно няма много заинтригувани от темата, почнах да си ползвам stripslashes-а, защото както казах по-горе изобщо не прави запис в базата ако има такива символи.

 

[sandh]

Тази презентация е интересна, а също така и тази книжка. Книжката я има на български, евтина е и съм почти сигурен, че има и безплатен e-book вариант.

Това разбиране, че данните трябва да минат през addslashes И през htmlspecialchars при запис в базата данни е напълно погрешно. Не разбирам защо всички в този форум го дъвчат.

Целта на addslashes е да ескейпва кавичките. Това е главния проблем при SQL инжекциите - че даден стринг излиза от ролята си на "данни" и влиза в ролята на SQL код. Ако погледнете презентацията ще видите защо mysql_real_escape_string е по-добрия вариант (алтернатива на addslashes), макар и пропуските на addslashes да не са чак толкова често срещани.

htmlspecialchars - тази функция се ползва преди каквито и да е данни да бъдат изписани в страницата. Тя ескейпва служебни символи в HTML, а не SQL. Освен да оплеска нещо - няма смисъл да се ползва при запис в БД.

Освен това ако не направите двойно ескейпване - няма да има нужда от stripslashes при изваждане на нещо от БД. Затова на изхода това също е лоша практика.

Накратко - при вход в базата данни: mysql_real_escape_string(), при изход на страницата: htmlspecialchars().

P.S. - а, да - strip_tags премахва таговете. Няма смисъл да минеш стринга през strip_tags, после през htmlspecialchars. Това значи, че нещо като:

1 < 2 и 2 > 0

Ще е невъзможно да се произведе в страницата, защото < 2 и 2 > ще бъде третирано като таг. Тук трябва да се ползва само htmlspecialchars, за да може < и > да се заместят от < и > без да се интерпретират като html код.

strip_tags( htmlspecialchars( $string ) );

Това е по-правилен вариант... и все пак функцията strip_tags е излишна, защото във всеки случай тя никога нищо няма да премахне след като htmlspecialchars вече е минала през стринга.

 

[relax4o]

Тука е често срещана практика да се ползват и двете наведнъж. Много пъти съм казвал, че трябва първо да знаете входящите данни къде ще отиват. Не винаги входа отива в SQL заявка, че правите постоянно htmlspecialchars(addslashes()).