Добре дошли!

Добре дошли в нашите форуми, пълни с полезна информация. Имате проблем с компютъра или телефона си? Публикувайте нова тема и ще намерите решение на всичките си проблеми. Общувайте свободно и открийте безброй нови приятели.

Моля, регистрирайте се за да публикувате тема и да получите пълен достъп до всички функции.

Как да се защитя от SQL injection ?

Последователи

26 януари 201115 г.

По твоя начин се губи напълно четимостта и възможността от коректни цитати в сайт като този.

Това, не е мой начин, а основен принцип в програмирането - данни се трансформират само при нужда и само на необходимите места! Т

Опитай се да ме цитираш и виж на какво ще заприличат тези символи:
\ " / < >

Мисля, че примера ще е достатъчно красноречив, защо не бива да се доверява човек на вградените функции.

Примера ти красноречиво показва, че ескейпващата функционалност си работи идеално...

27 януари 201115 г.

Красноречиво НЕ работи! Виждам наклонени черти. Което отново доказва, че е най-добре да си пишеш сам кода за обработка на $_POST и $_GET заявките. Много по-добре да обработиш допълнително всички специални символи, които вкарваш в базата данни от колкото да рискуваш четимостта на сайта. Каквото и се е получило с показания от мен пример.

27 януари 201115 г.

Хайде сега иди и прочети за XSS за HTML и JavaScript инджекшън и ще разбереш защо стандартните XML ентитита се ескейпват, а тези с десетичната цифрова репрезентация не се! Как иначе ще ти напиша: Азъ Бѹкы Вѣдя Гла̀голи До̀бро Эсть ... Забележи специалните буквичкии в unicode формат... Забележи сега и ескейпнатите ентити - г ҙ - светна ли ти защо е? И последното което имам да ти река момче, забележката която ти правя е не заради това, че сам си пишеш ескейпването (това е тема на друга бира, но също така лоша практика), а че променяш глобално изходните данни! Откъде ще ги вземеш сега, ако ти потрябват оригиналните стойности на параметрите? За това замяната се прави на място и при нужда!

27 януари 201115 г.

darkterminal, имаш право на гледната си точка, която според мен само довежда до по-голяма загуба от колкото печалба. На практика ти признаваш, че си склонен да изгубиш правилното изписване на определени символи за сметка на някаква сигурност. Аз казвам, че определени, може би не-повече от 10-на специални символа трябва да се прекарват през шкурка и то не избирателно (както ти се иска), ами абсолютно за всеки елемент на $_POST или $_GET.

И тъй като се чудиш "Откъде ще ги вземеш сега, ако ти потрябват оригиналните стойности на параметрите?"? Е как от къде?! Дано не питаш сериозно! Когато извличаш информацията от базата данни обработваш отново тези 10-на символи и им възвръщаш първоначалният вид, по същият начин както го правиш и с вградената функция, просто си пишеш една твоя си функция. Така нито се губи четимост, нито позволяваш в DB да попадат опасни елементи.

Темата за SQL-инжектирането не ми е особено интересна. Макар, че частично се получава интересен диалог. Има доста по-сериозни заплахи, които могат да те срещнат. Например някой отдалече да ти счупи Apache-то :speak: .

27 януари 201115 г.

И тъй като се чудиш "Откъде ще ги вземеш сега, ако ти потрябват оригиналните стойности на параметрите?"? Е как от къде?! Дано не питаш сериозно! Когато извличаш информацията от базата данни обработваш отново тези 10-на символи и им възвръщаш първоначалният вид, по същият начин както го правиш и с вградената функция, просто си пишеш една твоя си функция. Така нито се губи четимост, нито позволяваш в DB да попадат опасни елементи.

А ако имам примерно в данните &#x0433 като стринг и като unicode символ. След превръщането и двете стават &#x0433. Как да позная при обратната конверсия кое да обърна и кое не?

27 януари 201115 г.

...
На практика ти признаваш, че си склонен да изгубиш правилното изписване на определени символи за сметка на някаква сигурност.
...

Нямам повече въпроси към теб...

27 януари 201115 г.

Нямам повече въпроси към теб...

казано директно готов е да загуби данни. Ех, има разни хора... Не знам как е при него, но при мен данните струват доста пари и НИКОЙ не си и помисля да ги променя невъзвратимо

27 януари 201115 г.

А ако имам примерно в данните &#x0433 като стринг и като unicode символ. След превръщането и двете стават &#x0433. Как да позная при обратната конверсия кое да обърна и кое не?

Ти как би го на писал с htmlspecialchars(), така че да не промениш символите? Дай прост пример и ще се съглася напълно.

27 януари 201115 г.

Ти как би го на писал с htmlspecialchars(), така че да не промениш символите? Дай прост пример и ще се съглася напълно.

Съжалявам, но не това ми е областта на експертиза. Но по-горе споменах нещо, замисли се! Ако толкова искаш да променяш данни го направи така че да можеш при нужда да се върнеш в началното състояние. Иначе смятай информацията за частично (или пълно) безвъзвратно загубена

27 януари 201115 г.

Съжалявам, но не това ми е областта на експертиза.

Нямам повече въпроси.

27 януари 201115 г.

Нямам повече въпроси.

Да разбирам ли че смятате проблема за програмистки, а не проблем на сигурността? Ако да, ще си позволя да цитирам някого:

Нямам повече въпроси към теб...

1 месец по-късно...

20 март 201115 г.

htmlspecialchars ще ви защити от XSS инжекция, докато mysql_real_escape_string от SQL инжекция. Не се препоръчва ползването на addslashes. Второ: htmlspecialchars се ползва при изкарване на информация от MySQL защото иначе ще ви се пълни с излишни html entities.

Редактирано 20 март 201115 г. от dikidera (преглед на промените)