http___blog.petkanski.com_2011__1.xml
http___dummy2dummies.blogspot.com_2012_.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 1.2 1.3 2.1 3.1 4.1 4.2 5.1 5.2 5.3 5.4 6.1 6.2 7.1 8.1 8.2 8.3 9.1 10.1 11.1
Second order injections are the ones which are not widely discussed. Firstly these cannot be detected by tools and one needs to understand the application logic and flow to detect this. A code review is better to understand the injection. In general the Injections happen when the developer trusts the input/or fails to sanitize input to build up the query being used in the application. What are second order injection? Second order injections can be considered simmilar to the stored XSS. Injection does not directly yeild result but this injection is used at some other places insecurely causing the injection to trigger and yield results. As an Example to understand this imagine an application which allows user to create a user account in the system. Now a malicious user can try to inject SQL keywords in the user creation form which is nicely escaping dangerous characters by use of mysql_real_escape_string() and making it safe for that form. Because mysql_real_escape_string() escapes the dangerous chars, therefore if attacker tries to inject admin' OR 1=1-- in the username field, because of the function, the quotes would be escaped and input would become admin\' or 1=1--. If other values of form are valid, the user account is created with the name admin' OR 1=1-- . Now with the user created, he can login with newly created account and go to the password reset page. As this page is checking for old password , and building up a query behind the scene something like UPDATE users SET passwd="New_Pass" WHERE username="Username" and passwd="oldpassword" Now as the username is being taken from the database, the developer treats this as trusted info. As he is confident that initially there is no SQL Injection on the pages. This blind trust on the data from database is called without any escaping, thereby causing the username to trigger the SQL injection. The query becomes UPDATE users SET passwd="New_Pass" WHERE username =' admin' -- ' AND password=' old password '. Effectively SQLi working and changing the password of Admin user commenting out rest of query which is marked in brown A video demonstration for the same can be found on the location below.