2. Where is unsafe
Variables are ultimately processed by code, and the code ultimately depends on some system functions and statements to execute. Incorrect variables appear in dangerous functions. Congratulations, the vulnerability appears!
1 Sql injection vulnerability: According to our understanding, unsafe variables appear in the Sql function. There are many such statements in PHP in the system. There are the following code in the initialization file of Dz:
if($sid) {
if($discuz_uid) {
$query = $db->query("SELECT , , ='6' AS ipbanned, AS spageviews, , , AS discuz_uid,
AS discuz_user, AS discuz_pw, AS discuz_secques, , , ,
, , , , , , , , , , m.extcredits1, m.extcredits2, m.extcredits3,
m.extcredits4, m.extcredits5, m.extcredits6, m.extcredits7, m.extcredits8, , , ,
, , , , , , ,, ,
FROM {$tablepre}sessions s, {$tablepre}members m
WHERE = AND ='$sid' AND CONCAT_WS('.',s.ip1,s.ip2,s.ip3,s.ip4)='$onlineip' AND ='$discuz_uid'
AND ='$discuz_pw' AND ='$discuz_secques'");
} else {
$query = $db->query("SELECT sid, uid AS sessionuid, groupid, groupid='6' AS ipbanned, pageviews AS spageviews, styleid, lastolupdate, seccode
FROM {$tablepre}sessions WHERE sid='$sid' AND CONCAT_WS('.',ip1,ip2,ip3,ip4)='$onlineip'");
Find the US dollar symbol in the $db->query function. Haha, I found that there are several, which means there may be loopholes. Note that it is possible, because the current code security has been improved, and it is not easy to find a variable that no one cares about. Generally, variables will be properly tried out, but by following the $onlineip variable, you can find that this variable is basically uncontrollable, because this is extracted from the Http header. Most people don’t pay much attention to this, but the problem arises:)
It should be noted that the function creates a vulnerability, regardless of what the statement is, so as long as a variable appears in update, insert or select, the variable is controlled by us, and changing the variable can break through some limitations of the program (what we will talk about later) to control the execution of this SQL statement, then our vulnerability is valid, and whether it can be exploited depends on the specific environment.
2 Xs cross-site scripting vulnerability: This vulnerability is basically the client's Html injection vulnerability. If the user submits a variable containing <> or characters that can be interpreted as Html are sent to the database and then output from the database to the browser's browser, then there may be an Xss injection vulnerability. <> characters can lead to cross-site scripting attacks, but it should be noted that there will be such problems if you do not need to submit <>, which is misunderstood by many people. Suppose our input such as a url is ultimately placed in an Html tag, there are many cases because the user's avatar must be in this form:
echo "<img src=\"$url\">"
We have controlled the properties of img and implemented cross-site scripting attacks.
3 File contains vulnerabilities: This is mainly because the file contains functions including functions, require and other functions without restrictions, resulting in the user being able to specify the files to be included, such as the following code:
require_once ROOT_PATH."cache/style/$";
If we can control $cssname, we can control the content that needs to be included. The existence of the vulnerability depends on whether this variable can be controlled. If it can be controlled and used for.../jump, then :) As for the harm, that is, arbitrary code execution and directory traversal.
4 Direct writing to webshell vulnerability: This is seen a lot in some text databases. Some programs use text files as databases, so they inevitably use functions such as fopen, fread and fwrite. Open the help of fopen functions to see:
resource fopen ( string filename, string mode [, bool use_include_path [, resource zcontext]] )
From this help, we can know that if the first parameter of the fopen function can be controlled, some files that should not be opened may be opened. Other file functions are examples. Again, the environment of the variable determines its value :)
5 Code execution vulnerabilities: Functions that can cause this kind of vulnerability must have this kind of function. Common ones include the eval function and the preg_replace function. If there are statements that we can control in eval, then problems will arise. The second parameter of the preg_replace function may lead to problems in the execution of arbitrary code!
6 Absolute path leak: This is mainly caused by php errors. Using a non-existent file, an error in mysql query, and submitting a parameter that does not match the type to some functions will cause this problem. Generally, programs use @ to suppress the function errors, but there are still some methods of explosive paths! Some people say that a path cannot represent anything. In fact, a path can know the operating system, the path, and may know the configuration of the virtual host, etc. ,
7 Logical confusion
If a variable is used in logical statements such as if, it is likely to cause logical confusion, skipping the execution of some statements, etc.
Various other functions have problems
3. Filter and squander filter
Many people have noticed these security issues. PHP also includes its own security mechanism, that is, when GPC=On, the escaping of ' and " and \ , many programs also add these escaping themselves. Other scripting languages may not have this mechanism, but this idea is very good. When escaped, it can ensure that all the user's input is a string, no matter where the variable enters, including SQL query, cross-site scripting, etc., but there is a very important premise that the program you write must also treat all the input as strings. Obviously, if there are two statements below:
$query = $db->query("select * from user where uid=$id");
$query = $db->query("select * from user where uid='$id'");
Which one is safer? The first statement makes the assumption that $id is a numeric type variable, and the second assumes that the input is a character type variable so use '' to refer to it. If you submit php?id=1 and 1=2 for the first statement, it will eventually become:
select * from user where uid=1 and 1=2 //and 1=2 becomes an expression
select * from user where uid='1 and 1=2' //and 1=2 is still part of the string
Hope this gives you a little tip, but it's not just SQL injection! If it is a cross-site scripting vulnerability, we can also use the above idea. No matter what the user input is, filter it well, and then just treat the user's input as a string. However, please note that just an escape character \'It is likely to have a lot of meaning in html. You need to remove its escape in html and use the htmlspecialchars() function. Of course, it also needs to cooperate with the program's safe code. Let's give two examples:
echo "<img src=htmlspecialchars($url)>";
echo "<img src='htmlspecialchars($url)'>";
Which one is flawless?
The above example implies that if a variable can only be used as a string, it does not give it a specific meaning, and it cannot do anything. Then you may have thought that for the various vulnerabilities mentioned above, if you have to control the variables by users, then you just need to filter out characters with special meanings and then just use the input as a string, and then you can eliminate these vulnerabilities at the code level. For example, for fopen function, as long as we filter out the characters ../ and ..\, and then escape the user's input ", ' and null characters, etc., there is no problem. For the problem of writing webshell, you can escape the <> script tag characters by just building a database. If the generated file itself is a php file, you can limit the user's input to '' or within "". Everything is just characters, which is very similar to the defense of cross-site scripts! There are also some sensitive characters that may be generated by the program itself, as shown in the following code:
$deldb=explode("|",$imgdb['icon']);
This gives $imgdb['icon'] a sacred meaning, so when we deal with it, we must first clean the | in $imgdb['icon']!
Four Other questions
What I mentioned above is just some ideas when detecting vulnerabilities and patching vulnerabilities. Starting from functions, analyzing the processing of variables, but more often, the security of the program still depends on the programmer's clear ideas, but security is not just that, such as coding problems of GBK and Big5, as well as uploading issues. This is true for Php scripts, and so for other scripts
Previous page123Read the full text