CHAPTER 4 PROPOSED SCHEME
4.5 D ETERMINE CSRF A TTACK
As mentioned above, attacker injects malicious scripts into honest website and waits for victims to browse the vulnerability web page. Labeling mechanism can quarantine UCC and separate the untrusted part of contents. Once the malicious scripts launch attack, all requests are tagged with untrusted labeled. Furthermore, administrator creates the protection policies of critical services and stores them in database. Therefore, we can block CSRF attack effectively without modifying UCC if an HTTP request is tagged with untrusted label and wants to access critical services.
21 attack is simpler than system level access control. We focus on separating contents by trusted and untrusted authors instead of treating content as a unit. Hence we choose a role-based access control model.
First of all, we introduce notations in RBAC and than these symbols are connected with labeling mechanism. We discuss the properties of security information, confidentiality, integrity, and availability in RBAC. In the end, we formalize CSRF attack and our proposed scheme by RBAC.
5.1 Notation of RBAC
RBAC (Role-Based Access Control) is a well-known access control model [31]
and ensure the integrity and confidentiality of a system. In this section, we will introduce symbols of RBAC in Table 1.
There are three basic components in RBAC, Subject, Roles, and Objects. Subjects represent user, program or a basic unit, even a network computer. In our scheme, subjects are contents in a web page and contents can be classified by the identity of author. A role is a collection of job functions and dispatches permissions to each subject. We divide contents into two roles, trusted and untrusted, by authors’ and current viewer’s identity. The procedure of separating subjects is written as AR(s).
RA(s) means that one subject can perform one or more roles, but it can only use one
role at a time.
Objects stand for the target of a program or the destination of execution path.
Web services can be considered as objects because contents make use of browser for accessing resources in a website.
Table 1, description of symbols
Transaction is a transformation procedure plus a set of associated data items. To speak simply, it’s a transition path of web pages for reaching an object. Each role may be authorized to perform one or more transactions, TA(r). In addition, roles can be composed of roles. In other words, a higher level role can control all transactions of lower role. The most important symbol is “exec” which describes that whether a subject can execute a transaction or not under basic rules. Our proposed scheme can be drawn as Figure 9.
23
Figure 9, labeling mechanism with RBAC
5.2 Properties Analysis
In information security, there are three security goals: confidentiality, integrity, and availability. Now, we discuss the relationship between the three properties with role-based access control in our proposed scheme. As mentioned above, “exec” does not provide the rules of decision whether a procedure of accessing is legal or not.
Therefore each transaction and subject is restricted with three basic rules:
• Role assignment:
– ∀s: subject, t: transaction,(exec(s,t)⇒AR(s)≠∅).
Role assignment rule complete the confidentiality property. Confidentiality means that the secret information should not be accessed by unauthorized individuals or systems. In RBAC, each subject must be assigned to a role or roles. That is to say, contents cannot access web services if browser does not have session with the website.
• Role authorization:
– ∀s: subject, (AR(s) ⊆ RA(s)).
Role authorization rule can give the flexible ability to the system. In the reality environment, the active role of a subject changes frequently and this rule defines the changing is in scope. For labeling mechanism, the role of UCC depends on current viewer’s and authors’ identity. The changing of current viewer’s identity affects the result of dispatching role for contents.
• Transaction authorization:
– ∀s: subject, t: transaction,(exec(s,t)⇒ t ∈ TA(AR(s)).
Transaction authorization rule ensure the integrity property. Integrity is the term used to prevent authorized roles from executing improper transactions. For example, CSRF attack disrupts the victim’s session with website and mimics the victim’s identity to access web services. In RBAC, transaction authorization rule ensures that all transaction must be executed with proper authorized role.
Availability assures that resources on the website should be available when they are needed. Administrator should give a guarantee of web services operating normally in any situation, including power outages, hardware failures, and system upgrades.
However, this property is not in RBAC and CSRF attack does not break availability.
5.3 Integrity Property
In a CSRF attack, victim’s browser will be forced to send requests to website by malicious scripts, as if requests were part of the victim’s interaction with the website.
25
Browser leverages the session, such as cookies, and malicious scripts disrupt the integrity of the victim’s session with website. To formalize CSRF attack by RBAC, the result shows as following:
CSRF := exec(s,t) is true only if t ∉ TA(AR(s)), where s∈subjects, t∈
transaction
Obviously, CSRF attack violates transaction authorization rule. According to labeling mechanism, untrusted contents will be tagged with untrusted label and cannot access critical services. For current viewer, malicious scripts which can invoke CSRF attack are always embedded in untrusted contents. As long as we can ensure that malicious scripts cannot change or escape from the label, CSRF attack will never appear. Thus, the most important thing is to implement labeling mechanism with transaction authorization rule.
Chapter 6 Implementation
In section 4, we discuss that how to effective defeat CSRF attack with JavaScript functionality preserving at server-side. In order to prove that the proposed scheme is operable, this section will discuss the overview of labeling mechanism and focus on the challenges of implementation.
Labeling mechanism can be divided into two components in implementation, labeling function and quarantine policies. In Figure 10, we can see the position of components in reality situation. Note that, the labeling function and labels are generated from server-side.
Figure 10, design overview of labeling mechanism
6.1 Labeling Function
Labeling function has three requirements. The first one is to distinguish untrusted contents from trusted contents. And the second is to ensure that this relationship will not be broken by untrusted contents. The third requirement is to enforce every HTTP request must be tagged with corresponded label.
About the first requirement, web server can preprocess the content of response.
According to the discussion in section 4.3, if there are any data uploaded by other
27
users, they should be tagged with untrusted label at first. In current website, web server stores data with author’s identity, uploading time, and extra information in database. When a web page is requested by browser, web server can quarantine UCC by analyzing the identity of data. For untrusted part of UCC, web server should isolate untrusted contents by HTML iframe tag. In other words, untrusted contents are placed into iframes. The properties of iframe make sure that communication between trusted and untrusted label is still alive and all requests will be affixed with the same HTTP referrer header from iframe. Even if untrusted contents generate elements dynamically, HTTP referrer header will not be affected. Therefore, web server can dynamically generate response with iframe depend on identity provided by browser.
The second requirement is to restrict the access ability of UCC. Because iframe can communicate with parent node under the same website, we must setup a series of rules to restrict communication ability of UCC at client-side. Because our proposed scheme does not modify browser, we have to take use of JavaScript properties for restriction. JavaScript allows functions overriding and property redefine. For a configurable function or property, we can just assign a new object to override it. But some properties are non-configurable. In [14], authors use __defineGetter__, __defineSetter__, and Function.apply for changing the behavior of function and property. Redefining getter and setter is a useful skill for hiding non-configurable property, for example, “document.referer.”
Functions
XMLHttpRequest.open Function override
XMLHttpRequest.send Function override
Property
document.cookie Hide property
document.referrer Hide property
window.parent Assign new object
window.top Assign new object
window.opener Assign new object
window.self Assign new object
document.parentNode Return null by default
Table 2, modified functions and properties
In Table 2, there are four elements of window should be reconfigured because these elements let iframe access parent node’s resource. As long as trusted label is parent of untrusted label, untrusted label has no chance to access trusted label. To make sure that UCC is restricted by our rules, we can create a rule.js which is placed at <head> section [14] [15] and put other UCC in <body> section. Although the javascript file might be loaded many times, browser has cache mechanism for reducing the overhead of loading the same file. With this method, there is no way to access trusted label in an iframe.
Figure 11, put rule.js in header section
But, here comes another problem – if untrusted label include a frame which contains trusted label, untrusted label can access trusted label. In reality situation,
29
untrusted label can create another window object, an iframe object, and include trusted label page without any restriction. Because of no limitation on child node, untrusted label can access trusted label without obstruction. HTTP referrer header and function overriding can simply figure out this problem. To include a trusted label window means that browser has to send HTTP request and retrieve the sensitive data.
Once a HTTP request is issued, browser will automatically embed current URL as HTTP referrer header and server can know whether request is trusted or not depend on referrer header. Current browser supports HTTP referrer header which cannot be modified by AJAX [16]. For privacy concern, we setup a rule for disable JavaScript access to document.referer. To avoid potential threat, web server should make use of HTTPonly [16] [17] for protecting cookie. HTTPonly disallow JavaScript access to a cookie.
Table 3, browsers support HTTPonly
To meet the third requirement, we must know all methods that can send HTTP request to web server. With HTML, every tag which contains URL can be treated as a HTTP request, for example, <a>, <img>, <meta>, and <form>, etc. All of them will send HTTP request with referrer header. Hence, we can use referrer header to verify its label. By changing the path of URL, web server can easily know the label of
request. Apache modules support “AliasMatch Directive” which can map URL-path to local files. With this module, administrator does not need really change all paths.
AJAX has customizing HTTP header ability, so we can override XMLHttpRequest function and attach a label on AJAX HTTP request. Overriding XMLHttpRequest function guarantees that the label cannot be overridden. Although referrer header can help us, customized header can ease off the overhead of server-side processing.
JavaScript defined “delete” operator can erase a function or property. When a built-in function or property is deleted, the function overriding loses efficacy and built-in function or property goes back. To prevent this situation, ECMAScript 5th edition [18] introduce “strict mode” [19] which can disable delete operator.
6.2 Identify Page Session
Now, all browsers have tab function. Each tab stands for a window and they do not interfere with each other. However, web server only recognizes HTTP request which does not contain information about tab. If we identify the session without considering tab, different tab requests cause false positive sometimes. In order to avoid this situation, cookie path can solve this problem. Different path can setup different cookie. This method is compatible with the 3rd requirement of labeling mechanism using the path of referrer header.
6.3 Check Policy
At server-side, administrator of website should define policies which describe critical services. In popular social network websites, they have self-checking mechanism between each web page. In other words, we only need to tag correct label
31
on begin page and check end page. A policy format sketches as Figure 12.
The database of critical services is very convenient for administrator to add, delete, or adjust. Administrator only needs to setup the final web page of a service and the parameter of GET and POST. Once an untrusted label request is going to access one of web pages in critical database, the request should be block immediately.
Figure 12, critical policy format
When a CSRF attack is detected, the result of detection is forwarded to web server.
Administrator can acquire the result by calling “begin_check()” function implemented in labeling mechanism. Therefore, this scheme can be deployed easily by adding three lines to each web page with PHP and construct untrusted iframe elements.
Chapter 7 Evaluation
We conducted experiments to evaluate performance overhead of our proposed scheme. Result of the evaluation fall into three categories: time overhead, memory usage overhead and defense effectiveness.
7.1 Environment of Experiment
First of all, we show the environment of evaluation. The server-side and client-side environment are described in Table 4.
Server-side:
CPU Intel(R) Xeon(R) 3050 @ 2.13GHz
Memory 1024 MB
Operating system FreeBSD 8.0-RELEASE #1 Web server Apache 2.2
PHP 5.2.12 + MySQL 5.2 Client-side
CPU AMD Athlon 64 X2 4200 @ 2.2 GHz
Memory 2048 MB
Operating system Windows XP SP3 Browser Firefox 3.6.3
Table 4, environment of evaluation
Each test web page includes “check.php,” an 8.8KB file without compression.
And the untrusted iframe has to include a JavaScript policy file, rule.js. The size of
33
rule.js is 4.4KB and the line of code is 146. It is also uncompressed.
7.2 Page Generation Overhead
To evaluation page generation overhead, we modify the web pages of Facebook [20] and MySpace [21] by ourselves. These social network website are very popular now. We create a service which contains four essential web pages. And browser surf the service over one thousand times.
The page generation overhead of modified Facebook service is range from 1.3%
to 2.0%, but averaging a modest 1.6%. The modified MySpace service cost 1.8 % on average. The communication between browser and server is affected by the status of network connections, so we eliminate some irrational data which take less than 0.1%
of result.
Figure 13, page generation overhead
We also measure the exact time of each access between labels and services. We can see that the execution time is very low and users will not feel the latency in Table 5. The execution time consists of enforcing JavaScript rule file, PHP execution at server-side and database query. But the last one, database query time, depends on the
10500
architecture and the size of the website. The database’s size of popular social network website could be very huge and a data needs more time for querying, but database cluster system [23] and cloud computing technology [24] can decrease execution time effectively and make database query in real time.
Table 5, processing time of each access
7.3 Memory consumption
To calculate the memory usage, PHP provides memory_get_usage function for measuring the amount of memory allocated to PHP. We calculate the difference between memory usage of original architecture and policy-enforced in Table 6.
Table 6, memory consumption of accessing services
86 87 88 89 90 91 92
T → T T → U U → T U → U
Me mo ry(KB)
35
Another memory usage is HTML iframe tag. Because of our proposed scheme, iframe is used to quarantine untrusted labels and a web page might contain many iframe tags. Therefore, we calculate the memory consumption of an iframe in Figure 14. Each iframe costs 0.15MB on average. And the number of iframe inside a web page needs 10 at most by our observation in current websites.
Figure 14, memory consumption of iframe
However, parts of memory consumption sometimes are affected by the content of web pages and the structure of website, especially in social network websites. In conclusion, memory consumption of both server-side and client-side are acceptable in current environment.
7.4 Defense effectiveness
The goal of our defense is to be effective against a variety of CSRF attacks. This section will discuss all situations about the preventing CSRF attack.
CSRF attack in different websites: A traditional CSRF attack means that victims must visit the malicious website first, the malicious script can forge an HTTP request and the browser of victim is forced to send this HTTP request. In our labeling
mechanism, we can detect login CSRF by examining HTTP referrer header. In current browser, HTTP referrer header cannot be modified by JavaScript or HTML. Therefore,
0
we can use HTTP referrer header to detect all forged HTTP requests from different websites, for example, [44] makes use of the flaw of Ebay. In this case, labeling mechanism can easily block forged requests by checking HTTP referrer header.
There is a similar CSRF attack called “Login CSRF attack [32].” Its concept is to override the cookie of the victims. By observation, login page is the most dangerous page of a website because it often lacks protection. However, HTTP referrer header is a built-in header, so the login page is protected as well.
CSRF attack in the same website: This kind of attack often cooperates with XSS and attacker does not need to set up a website. Attacker uploads malicious scripts to honest website’s database at first. When victims surf the polluted web page, victim’s browser will execute malicious scripts automatically. Attacker takes advantages of AJAX which can create HTTP request and customize HTTP request headers for forging HTTP requests. To prevent multi-stage CSRF attack, labeling function ensures that UCC is isolated and every HTTP request is tagged with corresponded label. Once all forged requests are captured, CSRF attack can be blocked easily.
37
Chapter 8 Conclusion
In this paper, we pointed out the root problem of CSRF attack and introduced the severity of CSRF attack in current social network websites. After surveying current solutions, we found a novel approach that could defeat multi-stage CSRF attack effectively.
According to the root of the problem about CSRF attack, we proposed a light-weight labeling mechanism protection approach. This approach takes advantage of built-in methods and properties to reduce performance overhead instead of filtering or rewriting the suspicious strings. The administrator only needs establish policies for critical services and inserts suspicious contents into iframe tag. To fully utilize benefits of web 2.0, we maximize the usability of JavaScript and AJAX with little restriction. Users can still use the original JavaScript and AJAX syntaxes and semantics under labeling mechanism. For convenient (in convenience), we provide a safety website without altering the browser. The members do not need to install any plug-in or add-on for a specific website. In conclusion, the proposed scheme could prevent CSRF attack without blocking website’s interactive contents.
Chapter 9 Reference
[1] OWASP, “OWASP Top Ten Project,” 2010. Available:
http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project [2] Petko D. Petkov, “Google GMail E-mail Hijack Technique,” 2007. Available:
http://www.gnucitizen.org/blog/google-gmail-e-mail-hijack-technique/
[3] S. Kamkar, “I’m popular,” 2005, description and technical explanation of the JS.Spacehero (a.k.a. “Samy”) MySpace worm. Available: http://namb.la/popular [4] World Wide Web Consortium, “Document object model (DOM) level 2 core
specification,” 2000. Available: http://www.w3.org/TR/DOM-Level-2-Core/
[5] N. Jovanovic, E. Kirda, and C. Kruegel, “Preventing cross site request forgery attacks,” Securecomm and Workshops, 2006, pp. 1–10.
[6] Mario Heiderich. CSRFx, 2007. Available: http://php-ids.org/category/csrfx/.
[7] Eric Sheridan. OWASP CSRFGuard Project, 2008. Available:
http://www.owasp.org/index.php/CSRF_Guard.
http://www.owasp.org/index.php/CSRF_Guard.