Http Referer origin

To prevent CSRF attacks, we recommend modifying the browser to add an Origin field when sending a POST request, which is primarily used to identify where the original request originated. If the browser is not sure where the source is, the Origin field's value is empty in the sent request.

Privacy: This Origin field is more humane than referer because it respects the privacy of the user.

1. The Origin field contains only the requests originating from, and there is no other information (usually the scenario, the host and the port of the active document URL). Unlike Referer, the Origin field does not contain URL paths and request content that involve user privacy, which is especially important.

2. The Origin field only exists in the POST request, and Referer is present in all types of requests.

Clicking on a hyperlink (such as from a search list or a corporate intranet) does not send the Origin field, which prevents the disclosure of sensitive information.

In dealing with privacy issues, the Origin field approach may be more palatable to the user.

Service side to do: Use the origin field method to defend against CSRF attacks, the site needs to do the following:

1. The Post method must be used in all requests that can change status, including login requests. There must be a rejection for some specific get requests that can change status, in order to counter the type of damage posted on the forums mentioned above.

2, for those who have Origin field but the value is not what we want (including the value of NULL) request, the server must be rejected. For example, the server can reject all requests for outbound from the Origin field.

Security analysis: Although the Origin field is designed to be very simple, it can be useful to defend against CSRF attacks.

1. Remove the Origin field. Because browsers that support this approach take the source header with each post request, the site can determine whether the request was initiated by a browser that supports this method by looking at whether the Origin field exists. This design can effectively prevent an attacker from changing a browser that supports this method into a browser that does not support this method, because even if you change the browser to remove the Origin field, the Origin field is still present, but the value becomes empty. This is very different from referer, because Referer as long as the request is removed, the server will not be detected.

2. DNS rebinding. In the existing browser, the Xmlhttprequests,origin field for the same station can be forged. Websites that rely solely on network connections for authentication should use the DNS Rebinding method mentioned in chapter 2nd, such as validating the host field in the header. When using the Origin field to defend against CSRF attacks, it is also necessary to use the method of DNS rebinding, which complements each other. Of course, for the CSRF defense method mentioned in the fourth chapter, we also need to use the method of DNS rebinding.

3, plug-ins. If the site is prepared to accept a cross-site HTTP request based on Crossdomain.xml, an attacker could use Flash player in the request to set the Origin field. Token validation is not handled well when dealing with cross-site requests because token is exposed. In response to these attacks, the site should not accept cross-site requests from sources that are not trusted.

4, Application. The Origin field is very similar to the following four suggestions for determining the source of the request. The Origin field is based on the following four recommendations and has been improved, and several organizations have adopted the Origin field approach recommendations.



? Cross-site XMLHttp Request. The Cross-site XMLHttp Request method specifies a Access-control-origin field that is used to determine the source of the requests. This field exists in all HTTP methods, but it is only carried when the xmlhttprequests request. Our idea of the Origin field is derived from this suggestion, and the Cross-site XMLHttp request team has accepted our proposal to name the field "origin" uniformly.

? Xdomainrequest. In Internet Explorer 8 Beta 1, there is a xdomainrequest API that deletes the path and request content in the Referer when sending an HTTP request. The reduced Referer field can identify the source of the request. Our experimental results show that this truncated referer field is often rejected, but our Origin field does not. Microsoft has issued a statement that will use our recommendations to change the deletion referer in xdomainrequest to the Origin field.

? Jsonrequest. In the jsonrequest design, there is a domain field that identifies the host name of the originating request. In contrast, our origin field method contains not only the host, but also the requested scheme and port. The designer of the Jsonrequest specification has accepted our recommendation to change the domain field to the origin field to prevent network attacks.

? Cross-document Messaging. A recommendation in the HTML5 specification is to create a new browser API to verify that the client links between HTML files. This design contains an origin attribute that cannot be overwritten, and if it is not on the client side, the process of validating the Origin property on the server is the same as the process of validating the Origin field.



Implementation: We have implemented the method of using the Origin field on both the server and the browser to prevent CSRF attacks. In the browser side our implementation of the Origin field is, in WebKit add a 8 line code patch, Safari has our open source components, Firefox has a 466 line code plug-in. The way we implement the Origin field on the server side is that in the Modsecurity application firewall we use only 3 lines of code, adding an application firewall language to Apache (see Figure 4). These rules validate the host field and the Origin field with a valid value in the POST request. When implementing these rules to defend against CSRF attacks, the site does not need to make any changes, and these rules ensure that the GET request is not offensive (as long as the Origin field method has been implemented on the browser side).

Http Referer origin