My name is Johannes Dahse and I am studying “IT-Security” at the Ruhr University Bochum in Germany. Beside my studies I read a lot about websecurity and experiment with it, write some codes for smaller projects and love to participate at Capture The Flag-style webapphacking competitions. I also like to work out, and hang out with friends and grab some beers.
Contact: johannesdahse at gmx dot de
Hi,
i found your articles very informative. i learned a lot from it. thats why i want to thank you and provide you with some piece of information.
you wrote that there is no way to give a path to load_file not using ‘quotes ‘
actually there is a way:
SELECT CONCAT(’0x’,HEX(‘/path/to/file.php’));
that gives you a pathname in hex (could be done in other ways):
0x2F706174682F746F2F66696C652E706870
and now we can use it like this:
SELECT load_file(0x2F706174682F746F2F66696C652E706870);
and it works for me in 5.0.32-Debian_7etch6-log
hi, glad you like them. thanks for your hint but I was referring to INTO OUTFILE when I wrote that the quotes are definetly neccessary for the path. you probably mixed up the articles
load_file() of course accepts encoding as any other function, but INTO OUTFILE as being an operation, not a function, doesnt support a way to avoid quotes (afaik).
Hi,
just wondering what RIPS stand for?
Cheers,
Aoife
Hi,
actually it stands for Reiners Ironic PHP Scanner … ironic because it is a PHP app scanning PHP apps. However I find the acronym not really sexy so I never mention it anywhere
Cheers,
Reiners
Hi,
Thanks for all your great articles.
Is there any possibility of you adding an RSS feed to this page? I’d like to subscribe to it in my rss reader. Thank you!
hi,
you can use http://websec.wordpress.com/feed/.
hope that works
Sweet, thank you
Works great!
[...] man das Programm benutzt, rät der Autor zuerst das Infopaper zu lesen, welches sich -> hier <- findet. Zudem ist das Tool noch lange [...]
Hello
My name is Adela Kuźniarska and I represent PenTest Magazine- the only publication devoted to penetration testing
We are looking for authors who could provide us with some interesting articles concerning penetration testing and vulnerability management.
We need people to write influential article about the Nessus software by now.
I believe your expertise in this matter might be invaluable to our readers and maybe you could share your knowledge with us.
Would you be interested in hearing more details?
For more information please visit http://www.pentestmag.com
I am looking forward to hearing from you.
Best Regards
Adela Kuźniarska
PenTest Magazine
hi Johannes,
can I ask you how is it possible to make a blind query WITHOUT using query, when only other statements are available (i.e. case etc.)
I’ve seen you said it is possible -I tried to find a solution to that, but failed hard at…
…any idea or tip?
ooops, errata corrige:
“to make a blind query WITHOUT using a select statement”.
Without a select i’m limited to read variables like version etc., but cant understand how to access table contetns…
hi massi,
as stated here you can only access columns that are already in the field list (columns that are used in the original SELECT query you are injecting into).
Example:
SELECT name, password FROM users WHERE id = X
If you want to access the password column you dont need a subselect, because it is already in the field list:
X= if(mid(password,1,1)=0×61,1,2)
However if your desired column/table is not already in the field list, there is no way to access is without using another SELECT.
Cheers,
Reiners
hello,your blog is very nice,i am from china,i have learned a lot from your site,so,then,i have a question:
this url : http://websec.wordpress.com/2011/06/
this article,you say “mysql_real_escape_string” can be safe
// safe
$name = mysql_real_escape_string($_GET['name']);
mysql_query(“SELECT * FROM users WHERE name = ‘$name’”);
but i find that it is also vulnerable,when mysql’s character is gbk,
?name=%bf%27 will also work well in sql injection
yes it is insecure with some asian character sets, as described in detail here. however since those character sets are very rarely used (at least here in europe) one can assume that mysql_real_escape_string is safe. To be sure you should always use prepared statements. thanks for noting.