Сигурността е интересна концепция и привлича много хора към нея. За съжаление това е сложна тема и дори професионалистите я разбират погрешно. Открих дупки в сигурността в Google (CSRF), Facebook (повече CSRF), няколко големи онлайн търговци на дребно (главно SQL инжекция / XSS), както и хиляди по-малки сайтове, както корпоративни, така и лични.
Това са моите препоръки:
1) Използвайте параметризирани заявки
Параметризираните заявки принуждават стойностите, предадени на заявката, да бъдат третирани като отделни данни, така че входните стойности да не могат да бъдат анализирани като SQL код от СУБД. Много хора ще ви препоръчат да избягвате низовете си с помощта на mysql_real_escape_string() , но противно на общоприетото схващане ене всеобхватно решение за SQL инжектиране. Вземете например тази заявка:
SELECT * FROM users WHERE userID = $_GET['userid']
Ако $_GET['userid'] е настроен на 1 OR 1=1 , няма специални знаци и няма да бъде филтриран. Това води до връщане на всички редове. Или, още по-лошо, какво ще стане, ако е настроен на 1 OR is_admin = 1 ?
Параметризираните заявки предотвратяват възникването на този вид инжектиране.
2) Проверете въведените си данни
Параметризираните заявки са страхотни, но понякога неочаквани стойности могат да причинят проблеми с вашия код. Уверете се, че потвърждавате, че те са в обхват и че няма да позволят на текущия потребител да промени нещо, което не би трябвало да може.
Например, може да имате формуляр за промяна на паролата, който изпраща POST заявка към скрипт, който променя паролата им. Ако поставите техния потребителски идентификатор като скрита променлива във формуляра, те биха могли да го променят. Изпраща се id=123 вместо id=321 може да означава, че променят паролата на някой друг. Уверете се, че ВСИЧКО е валидирано правилно по отношение на тип, обхват и достъп.
3) Използвайте htmlspecialchars, за да избегнете показвания потребителски вход
Да приемем, че вашият потребител въвежда своето „за мен“ като нещо подобно:</div><script>document.alert('hello!');</script><div>
Проблемът с това е, че вашият изход ще съдържа маркировка, въведена от потребителя. Опитът да филтрирате това сами с черни списъци е просто лоша идея. Използвайте htmlspecialchars за филтриране на низовете, така че HTML таговете да се преобразуват в HTML обекти.
4) Не използвайте $_REQUEST
Атаките за фалшифициране на заявки между сайтове (CSRF) работят, като карат потребителя да щракне върху връзка или да посети URL, който представлява скрипт, който изпълнява действие на сайт, в който е влязъл. $_REQUEST променливата е комбинация от $_GET , $_POST и $_COOKIE , което означава, че не можете да разберете разликата между променлива, изпратена в POST заявка (т.е. чрез input маркер във вашия формуляр) или променлива, която е зададена във вашия URL като част от GET (напр. page.php?id=1 ).
Да приемем, че потребителят иска да изпрати лично съобщение до някого. Те може да изпратят POST заявка до sendmessage.php , с to , subject и message като параметри. Сега нека си представим, че някой вместо това изпраща GET заявка:
sendmessage.php?to=someone&subject=SPAM&message=VIAGRA!
Ако използвате $_POST , няма да видите нито един от тези параметри, тъй като те са зададени в $_GET вместо. Вашият код няма да види $_POST['to'] или някоя от другите променливи, така че няма да изпрати съобщението. Въпреки това, ако използвате $_REQUEST , $_GET и $_POST се забиват заедно, така че нападателят може да зададе тези параметри като част от URL адреса. Когато потребителят посети този URL, той неволно изпраща съобщението. Наистина притеснителното е, че потребителят не трябва да прави нищо. Ако нападателят създаде злонамерена страница, тя може да съдържа iframe който сочи към URL адреса. Пример:
<iframe src="http://yoursite.com/sendmessage.php?to=someone&subject=SPAM&message=VIAGRA!">
</iframe>
Това води до това, че потребителят изпраща съобщения до хора, без изобщо да осъзнава, че са направили нещо. Поради тази причина трябва да избягвате $_REQUEST и използвайте $_POST и $_GET вместо това.
5) Отнасяйте се към всичко, което ви се дава като подозрително (или дори злонамерено)
Нямате представа какво ви изпраща потребителят. Може да е законно. Може да е атака. Никога не се доверявайте на нищо, което потребителят ви е изпратил. Преобразувайте в правилни типове, валидирайте входовете, използвайте бели списъци за филтриране, където е необходимо (избягвайте черните списъци). Това включва всичко, изпратено чрез $_GET , $_POST , $_COOKIE и $_FILES .
Ако следвате тези указания, вие сте в разумна позиция по отношение на сигурността.
