Защита от XSS на WYSIWYG редактори

metal_head

Registered
Така, сега ВНИМАНИЕ :D :
В сайта си използвам WYSIWYG редактори. На потребителите ми не се налага да пишат BB кодове за нищо. Тоест те си пишат като в Word, редактора си генерира автоматично HTML и го записва в базата данни при натискане на събмит бутона.

Работата е там, че искам да сложа защита против XSS. В такъв случай htmlspecialchars не ми върши работа, защото тя ще премахне HTML-а и поста отива по дяволите, особено ако има картини, линкове...абе с htmlspecialchars не става в случая. От страшно много време търся класове и функции за филтриране на XSS атаките, но не мога да намеря нещо, което да работи добре с моята система. Най - големия проблем е, че всички класове и функции, които съм ползвал развалят линкове с GET променливи в тях. Например, ако сложа линк от You Tube, след записа в базата данни, линка ще изглежда така: http://youtube.com?v ... и до там, информацията се губи. Това е най - големият ми проблем. Искам да помоля, ако някой знае хубав клас за тази работа (дори да трябва да се купи)


И искам да попитам, монеже гледах във форума това парче код:

PHP:
header ('Content-type: text/html; charset=utf-8');
$queryString = strtolower($_SERVER['QUERY_STRING']); 
if (strstr($queryString,"<") OR strstr($queryString,">") OR strstr($queryString,"(") OR strstr($queryString,")") OR 
strstr($queryString,"..") OR 
strstr($queryString,"%") OR 
strstr($queryString,"*") OR 
strstr($queryString,"+") OR 
strstr($queryString,"!") OR 
strstr($queryString,"@")) { 
$loc = $_SERVER['PHP_SELF']; 
$ip = $_SERVER['REMOTE_ADDR']; 
$date = date ("d-m-Y @ h:i:s"); 
$lfh = "./adm/logs.php"; 
$log = fopen ( $lfh,"a+" ); 
fputs ($log, "Дата: $date | Атака от: $ip | Атака над: $loc?=$queryString\n<br>"); 
fclose($log); 
echo "<font color=black>Вашата атака беше записана, и скоро ще лапнете бана!</font>"; 
exit;
}

Как работи този код и какво точно прави? Казаха, че бил защита против най - известната атака.

Благодаря ви предварително! :)
 
QUERY_STRING връща всичката информация от линка след ?
Примерно ако имаш index.php?act=news&id=10
В случая ще вземе act=news&id=10
А ако се направи опит за SQL Injection да речем като се сложи '
То QUERY_STRING ще върне act=news&id='

След това с strstr се проверява за наличието на символите < > ( .. % * + ! @ и ако открие някой от тези символи в QUERY_STRING то приема че е направен опит за атака (след като се опитвате да се защитите от тези символи де) и записва ip-то дата и час в текстов документ (може да се направи и да работи с база данни).
След това изписва Вашата атака беше записана, и скоро ще лапнете бана!

И спира изпълнението на страницата чрез exit;
 
@proba Ами ако имаме следния линк:
site/profile.php?name=user%20name
Ще го разбере ли като опит за инджекшън? Имаме символа "%".


@Fakeheal В OWASP ги разглеждах всичките. Това, което ми даде ти не е предназначено за PHP.

Искам да попитам за HTMLPurifier. То си е голяма библиотека и искам да попитам заслужава ли си? Доколкото знам аз, тя е доста тежка.
 
metal_head каза:
@proba Ами ако имаме следния линк:
site/profile.php?name=user%20name
Ще го разбере ли като опит за инджекшън? Имаме символа "%".


@Fakeheal В OWASP ги разглеждах всичките. Това, което ми даде ти не е предназначено за PHP.

Искам да попитам за HTMLPurifier. То си е голяма библиотека и искам да попитам заслужава ли си? Доколкото знам аз, тя е доста тежка.

Ще го разбере като инджекшън. Не съм прочела добре мнението и затова дадох АнтиСами, не бях сигурна на какво пишеш. HTMLPurifier-а е добро решение за по-големи сайтове, в които има значение много за каква data влиза в базата данни. Може разбира се да си го орежеш от към функции и така да намалиш "тваренето" от него. А като ползваш htmlspecialchars не може ли да ползваш декодиращата функция, когато вадиш инфото от базта данни. Би трябвало да се получи добре, точно както ти искаш.
 
защо не изполваш
http://www.tinymce.com

хората се стремят да е максимално защитена като вход и изход на даните
 
А като ползваш htmlspecialchars не може ли да ползваш декодиращата функция, когато вадиш инфото от базта данни. Би трябвало да се получи добре, точно както ти искаш.

Какво имаш предид с това, нещо не разбрах много. Да се превърнат специалните символи в код и после при прочит обратно да се дешифрират и да се прочетат ли ? Но нали така няма да има никаква промяна в съдържанието и пак ще си го има XSS-a?
А иначе.. не съм сигурен, но мисля, че ти точно имаш регистрация в сайта, за който става въпрос или е просто потребител със същия никнейм:
http://media-swarm.com/profile.php?name=FakeHeal

Относно tinyMCE: Аз точно него ползвам - много е хубав и не ти позволява да правиш глупости, но какво става, ако някой си изключи джаваскрипта? Оп - обикновена textarea, в която можеш да си пишеш какво ли не. Това е проблемът.
 
Съжалявам за двойния пост, но аз все още не мога да открия решение на проблема ми, а сайта скоро искам да го пусна :(
 
Единственото решение, което е стабилно според мен е HTMLPurifier. Просто чисти HTMLа при добавянето. Какво като е голям, нали веднъж при добавяне ще го ползваш, не всеки път при показване.
 
Прав си, но в конфигурационния файл трабва да имам инклууднат auto loader-а през цялото време. Не знам той дали бави или не.

Другият ми проблем при HTMLPurifier-а е, че от тяхната INSTALL страница http://htmlpurifier.org/live/INSTALL нещо не ми стана ясно как ще го конфигурирам за моята система, въпреки че е даден дори пример.
Ето как стоят нещата при мен. Аз си имам конфигурационен файл, пълен с разни функции и какво ли не. В него се включват и други файлове. Имам си функция на име RestructureText и навсякъде от всяка форма за добавяне в сайта, текста минава през тази функция и се преправя (в момента съм махнал филтриращите функции, поради изброените от мен проблеми по-горе) и после се връща обратно за запис в базата данни.
Просто при такава механика не ми е 100% ясно как се използва HTMLPurifier.
 
Еми в тази функция правиш:

PHP:
include 'HTMLPurifier/HTMLPurifier.auto.php' // autoloadera на HTMLPurifier

$purifier = new HTMLPurifier();
$chistHTML = $purifier->purify( $_POST['...'] );

return $chistHTML;
 
И аз това мислех, че ще трябва да направя, но гледах, че има някакви специални конфигурации. И примерно сега имам този текст:

тестов текст с апостроф -> '
тестов текст с кавички -> "

Линк:
http://www.youtube.com/watch?v=UxmYLAd7RH4

Latinica

(Линкът автоматично се прави с <a> таг от редактора)

Та този текст след като мине през пюрифайъра става на това:

-> 'В
-> "
:
http://www.youtube.com/watch?v=UxmYLAd7RH4

Latinica

Линкът си работи, латиницата си остава, но българските символи изчезват. Също така се добавя буквата "B" след някои елементи...не знам защо. Четох в инсталацията, че трябва да се конфигурира енкодинг.
Аз в базата си данни ползвам cp1251_general_ci, как го задавам това.
<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Transitional//EN' 'http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd'>
Това е информацията за doctype-а ми, но не разбирам тя каква роля играе в HTML Purifier.
 
Много лошо, защото целия ми сайт и цялата база данни са с друг енкодинг. В такъв случай нищо не може да се направи. :/ Задънена улица. :(
 
Ми защото хакерите винаги намират начин да излъжат системата, пък в някои случаи имам разрешени страшно много тагове и атрибути (когато искам да дам на потребителите повече свобода за оформление).

Намерих в интернет това:
http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/

Някой ползвал ли го е, защото когато използвам функцията за филтриране, нещо се прецаква и всичко си спира изпълнението.
Ако това нещо работи, то ми е последната надежда.
 
До колкото си спомням от документацията на пюрифайъра можеше да се нагоди с друг енкодинг, но не ми е трябвало никога да го правя.
 
Хора, оправих си пробмела (надявам се...ще трябва да намеря някой доброволец да пробва да хакне сайта :D ) с htmLawed. Отначало имах някакви проблеми с него, но вие няма да имате, защото механиката на сайтовете ви едва ли е същата като моята.

http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/

Благодаря ви все пак на всички за предложенията. Ще дам точка на този, който има най - малко в случая :)
 

Back
Горе