Description: BLOG: http://dummy2dummies.blogspot.com
download and sync the new lab modules from the test bed link given below.
Part 16 of the Sqli-labs series based on error based sqlinjections, blind injection boolian type and time based type. This video covers basics of using file POST parameter -- INJECTION through a cookie (cookie based injections)
Link to part 1: http://www.securitytube.net/video/4171
Link to part 2: http://www.securitytube.net/video/4200
Link to part 3: http://www.securitytube.net/video/4208
Link to part 4: http://www.securitytube.net/video/4210
Link to part 5: http://www.securitytube.net/video/4269
Link to part 6: http://www.securitytube.net/video/4283
Link to part 7: http://www.securitytube.net/video/4303
Link to part 8: http://www.securitytube.net/video/4326
Link to part 9: http://www.securitytube.net/video/4399
Link to part 10: http://www.securitytube.net/video/4532
Link to part 11: http://www.securitytube.net/video/4650
Link to part 12: http://www.securitytube.net/video/4667
Link to part 13: http://www.securitytube.net/video/4672
Link to part 14: http://www.securitytube.net/video/4672
Link to part 15: http://www.securitytube.net/video/5104
Link to part 16: http://www.securitytube.net/video/5562
Link for test bed: https://github.com/Audi-1/sqli-labs
Tags: sqli , SQLi , Sqli-Labs , sqli-labs walkthrough , SQL injections , sqli-labs , learn SQLi , learn sql injections , outfile , dumpfile , load_file , post sqli , sqli in POST , double query injection , update query injection , sqli in insert query , sqli in header , header based sqli , cookie injection , sqli in cookie , second order sqli , second order injection ,
Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying.
Its been nearly 2 months back where your last video on sqli is posted on Sun 26 Aug 2012. kindly post videos in regular intervals of time. Thanks audi for your contribution.
@pentest
Thankyou for waiting for the video's.
I am eager myself to share what little i know but life is not a streamlined routine. The priorities change with change in circumstances around you. I had an OSCE course lined up in those 2 months and became a proud father of a beautiful daughter. I am not explaining or giving an excuse, I promise, I would try to be regular in future. Any time you wanna be in touch you can catch me on irc.freenode.net channel #offtopicsec or #offsec.
@Audi Its great to hear that you have became a father...!!! Thanks for your contribution :)
Yayyy, Audi is Back :) Nice to Hear You have became a father :) and your stuff is really helpful for me, Thanks a lot for contribution :D
@Audi Hi mate, i thought that you primer end up already. Now i see new video, what a lovely surprise. This one was really good. Changing admin's password to yours, so you can log-in as admin with all privileges. I have a stupid question: this will only work, if the developer did not sanitize user input from ' -- # " and other symbols, right?
@loop-back
If you check the sources of the file login_create.php line 25,26,27, the input username, password fields are sanitized for sqli elements. same happens with other input fields on login.php and pass_change.php. I am using mysql_escape_string and mysql_real_escape_string() function for it to just make it work in this case. This makes these fields safe for the scenario. Non of the fields is directly injectable. When attacker inputs admin' -- # then the quotes, slashes get escaped by appending a slash in front of them, for example admin' will be seen as admin\' so as the attacker should not be able to escape the string boundary and execute code. mysql_real_escape_string is considered pretty safe generally.
Problem in this case is, the injection we do does not work on input fields and a user gets created like admin\' --
thereby effectively creating a user admin'-- . Problem occurs on the change_pass.php where a logged in user is gonna change his password, and then the application collects the username from database() trusting the database info and put it in the update query, causing the injection to occur.
Summing up, this is happening because the developer is trusting anything he receives from db and does not sanitize that information and uses it directly in the query. If you wanna discuss this more, you can contact me on irc.