http___blog.petkanski.com_2011__1.xml
http___funkatron.com_posts_god_dammit_would_you_answer_the_question.html.xml
1.1 1.2 1.3 2.1 2.2 3.1 4.1 4.2 4.3 5.1 6.1 6.2 7.1 7.2 7.3 8.1 9.1 10.1 11.1 12.1 13.1 13.2 14.1 16.1 17.1 18.1 19.1 19.2
Доста време не съм пускал нови статийки в блога, но така е когато времето е в сериозен минус. Не успявам да се справя дори със задачите които съм обещал преди повече от месец, какво остава да намеря свободно време да пиша на свободна тематика. Ники Василев ме чака вече не знам колко време за едно елементарно скриптче, а аз се мотам ли мотам.. Луда работа. По темата.. Днес ми се наложи да сравнявам предимства и недостатъци на няколко framework-чета. При едното от тях липсваше вграден database model, така че се наложи да ползвам нещо отделно. В конкретният случай се спрях на PDO и реших да си напиша няколко базови класчета.. За да съкратя историята, направо ще ви синтезирам това което Ви е нужно да знаете ;) При МySQL имате два вида сравнение на низ от символи (string) - това са равенство и сравнение с pattern, посредством LIKE или регулярен израз. В моят случай използвам LIKE, защото е най-бърз за имплементация и защото отговаря на нуждите ми и няма смисъл от overengineering. Случаят е простичък - имам данни в базата, имам и търсачка която търси с LIKE. Това което ме изненада, беше, че mysql_real_escape_string() допусна символи в низа които са със специално значение, а именно - символите за процент (%) и долно тире (_). В най-общият случай - при вмъкване на данни или сравнение със равенство това не ви бърка, но когато ползвате LIKE нещата стоят по малко по-различен начин. Получи се ситуация, при която аз търся в базата данни къде е споменато "100%", но тъй като символът за процент не се escape-ва, се получава, че търся низ който съдържа 100. Query-то което се генерира е следното: SELECT * FROM SomeTable WHERE `textField` LIKE '%100%%' Очевидно, това не е поведението което би се очаквало, след като имаш илюзията, че данните са ти escape-нати правилно. След като разбрах какъв е проблема си помислих, че може би е проблем на mysql_real_escape_string() и веднага си отворих http://www.php.net/mysql_real_escape_string - но се оказа, че това е очаквано поведение. В документацията на функцията ясно са писали, че тя "prepends backslashes to the following characters: \x00, \n, \r, \, ', " and \x1a". Ето го точният цитат от сайта mysql_real_escape_string() calls MySQL's library function mysql_real_escape_string, which prepends backslashes to the following characters: \x00, \n, \r, \, ', " and \x1a. This function must always (with few exceptions) be used to make data safe before sending a query to MySQL. Може би символите за wildcard попадат точно в тези изключения които са споменали. Изводът е простичък - винаги минавайте един профилактичен str_ireplace() или preg_replace() на данните които използвате при генериране на заявка за търсене в базата данни за да няма изненади. Нека това, че ползвате prepared statements не ви дава чувство за сигурност.
1.1 2.1 3.1 3.2 3.3 3.4 4.1 5.1 5.2 6.1 7.1
God dammit, would you answer the question? I just LOVE it when I ask a very straightforward question on a mailing list, and get an “answer” that doesn’t address it at all. Folks,The php mysql api has a function "mysql_real_escape_string" that seems to be able to thwart known SQL injection attacks -- at least the ones of which I and other people I've discussed this with know. I am curious to know if pg_escape_string is as effective. If not, what would need to be modified to make it more effective? (there is a possibility that I may be able to get a grad student to work on this at the center, so detailed responses would be appreciated.) The best advice is to use bind parameters rather than trying to build SQL strings consisting partly of user input. Yes, that’s not bad advice, and I’m sure you’re just trying to help, but could you ANSWER THE FUCKING QUESTION? Or, if you don’t know, DON’T ANSWER. rarr. Original link: http://www.livejournal.com/users/funkatron/102198.html