Web application input attacks and Prevention

1. attackers bypass identity authentication.

Imagine a simple user login program: it obtains the username and password through the form, but sends the data to the server, the server program searches for the database and verifies the user identity. This authentication method is very common. When checking the username and password, many developers use the following code:

Note: In the above Code, the program extracts the username and password from the form data, and then directly passes it to the verified function ispasswordok. SQL commands used to query databases are constructed directly using form input data. This is an insecure process. Assume that the username is "Mikey" and the password is "& Y-) 4hi = qw8", the SQL command used to query the database is:

Select count (*) from client where (name = 'mikey') and
(Pwd = '& Y-) 4hi = qw8 ')

When count (*) returns an appropriate value in the query result, the user's "Mikey" authentication passes. If the return result of Count (*) is 0, the matching record cannot be found in the query, and the user is denied access.

So how can attackers bypass this verification process? First, the attacker will assume that the verification process uses the preceding SQL command for verification, and then they will send forged usernames and passwords to change the judgment logic of the SQL command. For example, if the username entered by the attacker is "X 'or 1) or ('1" and the password is "anyoldpassword", the SQL command used to query the database will become:

Select count (*) from client where (name = 'X' or 1) or ('1 ')
And (Pwd = 'anyoldpassword ')

It can be seen that the number of rows selected by this query is always greater than or equal to 1, that is, the return result of Count (*) is always 1 or greater. Therefore, although the attacker does not know the valid username and password, he can always pass the authentication!

Note the following five points to prevent attackers from bypassing the web application authentication process.

Ii. prevent leakage of error information

Do not return an error message with an SQL command error to the browser. When a script error occurs, IIS returns a-error by default. In fact, returning error messages without debugging information is more secure. For example, when we enter a forged username and password in the login form, the server may return the following error message:

Error Type:
Microsoft Jet Database Engine (0x80040e14)
Syntax error (missing operator) in query expression
'(Name = 'X' or 1) or ('1') and (Pwd = ''p ')'.
/Login. asp, line 24

As you can see, the error message contains some SQL commands, which will help the attacker correct the original error, it makes it easy for attackers to quickly construct valid usernames and passwords in SQL commands, although forged.

To reduce the error information returned by the server, modify % winnt %/help/IISHelp/500-100.asp or create a new file and set IIS, the server returns the new file when the 500.100 error occurs. To set up an IIS server, follow these steps:

1. Open the IIS management tool
2. Right-click the Web server to be set
3. Select "attribute"
4. Select the custom error Tab
5. enter the name of the custom 500.100 error page file.
For security, it is recommended that the physical path on the server never appear in the error message. For example, the error message "cannot find the foo.doc file in the C:/wwwroot/secretlocationdirectory" is not safe. A simple 404 prompt is enough.

Iii. Determining legality rules

Using VBScript, JScript, and Perl regular expressions, we can define validity rules for user input data. Do not analyze which input data is illegal, because attackers will find a way to bypass the illegal data check rules. For example, to prevent users from sending HTML data to the website, replace the "<" and ">" symbols in the input data:

Strinput = strinput. Replace (/[<>]/, "");

In the preceding statement, replace the "<" and ">" symbols with empty strings. So, can the HTML sent by attackers no longer be sent to the server? The answer is no. The attacker only needs to replace "<" and ">" with the corresponding HTML Entity symbol, and the above analysis of the code entered by the user cannot find the HTML. Therefore, we realized that the correct method should first determine what is legal, then verify the legality of user input, and reject all inputs that do not comply with the legality rules:

If (strname. Search (/[^ A-Za-Z 0-9]/)! =-1) return false;

This line of code searches for strname. If strname contains characters other than uppercase letters, lowercase letters, numbers, and spaces (meaning ^), the input data is denied.

During input validation, you must also note the forged file name. Attackers may try to send data to some sensitive locations, or send a request to obtain the source file. The following regular expression strictly limits the file name. The rules for legal file names are described as follows:

● One or more 0-9a-za-z or _, plus

● One or more 0-9a-za-z,-,/,/, and _, plus

● One sentence, plus

● '', 'Txt ', 'jpg', 'jpeg ', 'gif', 'htm', 'html', 'png ', 'bmp', or 'zip'

The names of all files that do not comply with the preceding rules are invalid. The file name rules are very strict, but they are valid. As you can see, the file name cannot start with a slash, because the slash is the root directory of the disk. In addition to attackers, who else needs to access the disk from the root directory? All access to files should be relative to the root of the web site:

VaR strinput = request. Form ("FILENAME ");

VaR Re =/^ [/W] {1,} [/W/-//] {1 ,}/. (txt | JPG | JPEG | GIF | HTM | HTML | PNG | BMP | zip)

{0, 1} $/I;

VaR fisfilenamevalid = (Re. Test (strinput ))? True: false;
4. Correct quotation marks

Quotes are sometimes difficult to handle because they interfere with SQL commands. As an example at the beginning of this article, attackers can use quotation marks to change the logic of SQL commands, so that users who do not have valid usernames and passwords can also log on to the system. Another method to prevent the use of quotation marks is to escape the quotation marks in advance. The following regular expression replaces all single quotes and double quotes with two single quotes and two double quotes respectively. The replaced SQL command is fully compliant with the SQL syntax, and it makes many attacks more difficult.

Strpwd = strpwd. Replace (/([/'/"])/g," $1 $1 ");

This statement can replace the previously added regular expression. But they can also be used together to strengthen defense!

Current location> Technology homepage> website development> Web Server

Web application input attacks and Prevention

Time: Author: Cactus studio enet Technology

　

5. Check the data returned by the SQL query

One way to completely prevent such attacks is to stop using the count (*) that can only represent "yes" and "no (*), check whether the username and password match the username and password returned by the SQL command. The Code is as follows:

VaR strsql = "Select name, PWD from client where" +

"(Name = '" + strname + "')" +

"And" +

"(Pwd = '" + strpwd + "')";

VaR ors = new activexobject ("ADODB. recordset ");

ORS. Open (strsql, oconn );

Fallowlogon = (ORS (0). value = strname & Ors (1). value = strpwd)

? True: false;

If no data is returned in the SQL query, the program triggers an exception, which is then caught by catch.

6. Disable parent path

Make sure that the file name does not contain "..". To disable the parent path, follow these steps:

Right-click the root of the web site and select "properties" from the menu ".

● Select the "home directory" tab.

● Click "Configure ".

● Click "application options ".

● Disable "enable parent path ".

To disable the parent path from the command line, run the following command:

Cscript adsutil. vbs set w3svc/1/root/aspenableparentpaths false

To fully prevent input attacks, you must have all input data to be prepared. Check valid input, rather than illegal input, because attackers can quickly find a way to break through illegal rules. At the same time, learn and use regular expressions correctly. By remembering these points, you can greatly reduce the chances of Web application intrusion.