Talking about the Web App secondary vulnerability-vulnerability warning-the black bar safety net

ID MYHACK58:62200819294
Type myhack58
Reporter 佚名
Modified 2008-06-08T00:00:00


On the assumption that design does not exist on the problems that people solve an application problem does not exist, and the use of language, and other peripheral component is a secure case, the program of the vulnerability on most of is due to in the implementation process, the programmer for the security of the disregard or the safety of Don't know the cause, and from the procedural point of view, this vulnerability is nothing more than insecurity of the parameters entering the unsafe operation caused. Unsafe operations we all know there are many, such as read and write files, database queries, code execution and some other dangerous function to use, etc., then the unsafe parameter is mainly what? Someone said all the user's inputs are harmful, it seems to me the input can be divided into two kinds, the direct input and indirect input. Direct input can be seen, such as url parameters, the browser and the server some of the environment variables, the user submits the Cookie, the user through form inputs, etc., for these input most of the programmers are in a safe on the comparison care comparison note that the parameters of the filter, because these inputs are obvious, the trigger is relatively simple, even some input if you have not done the filter will cause the program to error, plus PHP this language for some of the incoming parameters to the default protection Magic Quote option, so this parameter is now the largest program in relatively few problems, but in addition an implicit input has been ignored, that is from the database including Mysql this databases, text databases, and some commonly used cache and php configuration files, and so on, you can try to program to do a flow chart:

| Process flow user input==========> program processing filter)=========> data storage==========> program processing==========>output to the user Data flow raw data such as’=======> program processing secure data, such as\’)==> Mysql stores the original data as’)========>program processing process The is the’)=========>output to the user

You can see that if the user's input and temporarily stored in the database and then be removed to use without the added filter of words is very dangerous, because this time data is the user input of the original data is not affected by GPC and other security measures to protect, in addition to it is this vulnerability to trigger the condition than to the user's input to some operation, so the General test is more difficult to find, and can be mistaken to be safe. The above model is only briefly described problems exist, the reality completely is not limited to the above-mentioned’and mysql, etc., in fact, moving the network using a’convert’the Sql injection method is still very dangerous, it is vulnerable to this attack, in fact I also found this issue: from the programmer's point of view think, when will this security issue? Data needs to be temporarily stored somewhere, then in another place the need from the inside out to operate, then when will this when will prone to problems? Such as the time of registration of the user name, if allowed’, then it is equal to is the Bane of the introduction, because many places require the use of a user name, and user name is stored in the database, if in the latter operation does not accidentally put the username removed sent directly to the database operation will be a problem or is the user name into the session and then operation, this case can be viewed as a database-to-database Operation, not affected by GPC impact of course will be problems! Of course the problem is not just’for file operation in the\0? Will usually be addslashe the\0, if there is directly from the database to the file operation of the Data Flow, the danger is great. And in the programmer's eyes, may unconsciously believe that from the database out of something is to check something, but in fact often the opposite. So how to avoid and detect this vulnerability? For developers first is good programming practice and security awareness, understand the database and cache files out of something like unsafe, the second is during the data filtering time, don't just temporarily make the data lose harm, can be considered permanent to allow data loss hazards, such as in the filter of when not to’turn into\’, etc., but in the conditions allow it directly into HTML Characters', this does not affect the display but the data no longer contains a database of meta-characters so don't worry about the injection, other characters can be just as to consider treatment. In addition is to try to database strict design, in fact, in the storage process with a layer of implicit data filter, such as the data field size limit for the data length, the data field type limits the type of data, so we try to in the conditions allowed the use of a digital type of the field, and try to the data field of size reduction, either in the storage or security on or very meaningful. For the detection of personnel, if it is a white-box operation, the database can be of character type of a field is taken out, then the program checks these fields where, in fact, is the view into the hidden input on the check for problems, such as I here there is a section to check the type of the code:

<? php /Codz By Kenshin/ $host=’localhost’; $user=’root’; $password=’loveshell’; $dbname=’discuzl’;

$link = mysql_connect($host, $user, $password); if (!$ link) { die(’Could not connect: ’ . mysql_error()); } echo "Connected successfully\r\n"; if(mysql_select_db($dbname, $link)) { echo "Select Database successfully\r\n"; }


while ($row = mysql_fetch_row($result)) { print "Table: $row[0]\r\n"; print"+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\r\n"; $result2=mysql_query("show full fields from $dbname.$ row[0]"); while ($row2 = mysql_fetch_row($result2)) { if(strpos($row2[1],’int’)===false&&strpos($row2[1],’enum’)===false&&strpos($row2[1],’decimal’)===false&&strpos($row2[1],’date’)===false){ print "fields: $row2[0]\t\t attribute: $row2[1]\r\n"; } } print"+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\r\n"; } ?& gt;

Then you can focus on these fields to examine the problem, of course, not all fields can be controlled, attention to the field of insert, update operation can know the input can have what to change, and select after the operation can check these fields will go into what dangerous operation, and if it is the Black Box operation, because the code is opaque it can only according to their own some probes to guess the other's code is how to achieve to detect whether it contains a secondary vulnerability. The article is relatively simple, expect more sense out of things, for example based on the database of the Fuzz, and so on.