URL shifting and the URL validity check
Our solution can be generally divided into two parts, namely the URL shifting and the URL validity check. The URL shifting is responsible for changing dynamically the URLs in responses and binding these shifting URL with the users' identities, to realize "one URL one user." URL validity checking is responsible to check whether the request is valid according to the information stored in the system.
We will describe the proposed solutions in the following, including the system architecture, key technologies, and related processes. The main key technologies involved in this solution include URL shifting, binding mechanism of virtual URL and user identity, user access validation.
3.1 The architecture of AULS
The architecture of AULS system is as illustrated in Fig.1. It consists of three components: URL shifting module, URL checking module, and URL conversion module.
The URL shifting module replaces all URLs in the response from the web server with virtual URLs generated at random. It also binds the shifting URLs with the user identity, and forwards the response transformed to the client.
The URL validity check module receives the request from the user and examines the validity of this request. If the request is valid, the URL conversion module translates the virtual URL with the original URL, and forwards this request to the web server.
3.2 URL shifting
The URL shifting involves the dynamic URLs generated in the client side, the static URLs and the dynamic URLs (include the form URLs) generated on the server side.
The client-side dynamic URLs refer to these URL addresses that generated during page rendering. After web 2.0, there are a number of dynamic links generated by the client of the web applications. When the web service is accessed through these URLs, AURLS will block these requests to cause the user to fail to access the application.
Our solution to the problem is as follows. First, we use a taint analysis method [2-4] to find the web pages that are with the client dynamic URL, then obtain the data about client's dynamic URL, and save to the system database. When a response is received, AULRS checks whether this response is with some client dynamic URLs. If it is, AURLS will look up the string associated with the client dynamic URL, then does the URL shifting and make a binding between shifting string and user identity. The subsequent URL validity check is based on this information of the shifting string.
The shifting for static URL and dynamic URL in server side are directly replaced by a random string. The shifting for the form dynamic URL in the server side is similar to a client's dynamic URL string replacement, which also uses a tag and fixed length approach.
3.3 The binding mechanism of virtual URL and user identity
The simple URL shifting technique can reduce injection points on a web system, which makes it difficult for a hacker to forge an attack code. When a web page is accessed, the simple URL shifting method replaces all the URLs it contains with randomly generated URLs and associates the real URLs with the generated virtual URLs. However, because the generated URLs are not associated with the user, the URLs of the page will be shifted again when the page is revisited. This will cause a lot of redundant mapping data of virtual URL and real URL in the system, which will greatly reduce the system processing efficiency and increase the page access time, resulting in a serious deterioration of user experience of web access. In addition, after the attacker steals cookies from other users, the attacker can get a valid shifting URL for subsequent attacks.
To solve the above problem, we propose the binding mechanism to associate the user identity with the virtual URLs. For the same user, the corresponding shifting URL is only generated once for the same URL when the binding technique is adopted. If the attacker tries to construct a malicious script and defraud the user's access, like phishing and CSRF, because The URL in the request does not match the victim's identity, this access will be rejected. The binding mechanism is design as follows:
(1) Each user is identified with a unique token, such as a GUID.
(2) To establish the following mappings: a) the mapping of virtual URL and GUID; b) the mapping of virtual cookies and GUID; c)the mapping of GUID and the pair of user IP and virtual cookie; d) the mapping of virtual cookies and real cookies.
(3) When an HTTP request is received, AURLS detects whether the URL in this request is a virtual URL. If it is not, AURLS checks if this URL is in the white list. If it is not in, AURLS blocks this access. Otherwise, AURLS checks whether this request is with a virtual cookie. If it is not with, this visit can be determined as the first visit of this user. If it is with, there may be two cases. The user visits the home page again, or the attacker accesses the home page with other users' virtual cookie. To distinguish between the two cases, AURLS first gets the obtains user identity according to the cookie carried by the request, then checks whether the IP address of this request is same to the one in the user identity. If they are not consistent, it means that the attacker stole the user's virtual cookie. If they are identical, it's a case of the user accessing the home page again. If the request carries a virtual URL, AURLS will compare the cookie's value in this request to the virtual cookie in user identity. If they are different, this request is invalid and be blocked. Otherwise, AURLS will check whether the IP of this request is same to the IP in the user identity. If they are identical, this request is considered as a valid one. Otherwise, AURLS will redirect this request to the system authentication page.
(4) Maintenance of virtual cookie and real cookie mapping relationships. When the web server returns the latest new cookies, AULRS updates the key-value pairs for the virtual cookie whom the user bound.
3.4 The check approach for the validity of user access
There are several criteria for determining URL validity. (1) In URL white list and without a virtual cookie; (2) In the URL white list and with a virtual cookie, but the virtual cookie whom it carries and IP address are consistent with the virtual cookie and IP of the corresponding user; (3) Not in the URL white list, but the virtual cookie whom it carries is consistent with the virtual cookie of the corresponding user. (4)No violation of user access policy.
Compared with the access control based on the IP address, each request in our solution is corresponding to a specific user, so AURLS can perform a finer user access control.
The user access control of AURLS includes the total number of visits, the access frequency, the maximum access interval, and the 2-gram access behavior model for a specific virtual URL. In the following sections, we introduce the URL shifting procedure, and the URL validity checking and conversion procedure in detail.