Identifying Cross Site Scripting Vulnerabilities in Web Applications
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Identifying Cross Site Scripting Vulnerabilities in Web Applications

on

  • 15,041 views

Cross Site Scripting (XSS) is a vulnerability of a Web Application that is essentially caused by the failure of the application to check up on user input before returning it to the client’s web ...

Cross Site Scripting (XSS) is a vulnerability of a Web Application that is essentially caused by the failure of the application to check up on user input before returning it to the client’s web browser. Without an adequate validation, user input may include malicious code that may be sent to other clients and unexpectedly executed by their browsers, thus causing a security attack.
Techniques to prevent this type of attacks require that all application input must be checked up and filtered, encoded, or validated before sending them to any user. In order to discover the XSS vulnerabilities in a Web application, traditional source code analysis techniques can be exploited. In this paper, in order to assess the XSS vulnerability of a Web application, an approach that combines static and dynamic analysis of the Web application is presented. Static analysis based criteria have been defined to detect potential vulnerabilities in the server pages of a Web application, while a process of dynamic analysis has been proposed in order to detect actual vulnerabilities. Some case studies have been carried out, giving encouraging results.

Statistics

Views

Total Views
15,041
Views on SlideShare
15,041
Embed Views
0

Actions

Likes
1
Downloads
26
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Identifying Cross Site Scripting Vulnerabilities in Web Applications Presentation Transcript

  • 1. Identifying Cross SiteScripting Vulnerabilities in Web Applications P. Tramontana, A.R. Fasolino Dipartimento di Informatica e Sistemistica University of Naples Federico II, Italy G.A. Di Lucca RCOST – Research Centre on Software Technology University of Sannio, Benevento, Italy M. Mastroianni Second University of Naples, Italy 1
  • 2. The problem of Internet security and privacy Security and privacy are fundamental requirements for Web Applications 75% of the malicious attacks on the Web occur at the application level (Gartner Group) As more complex and automated Web Applications arise so does the probability of creating security loopholes. 2
  • 3. The problem of Internet security and privacy Security and privacy are usually guaranteed by:  specific security systems (such as firewalls, or Intrusion Detection Systems) and software (such as antivirus or encryption software)  organisational changes to business processes finalised to improve security But developers do not build security into theirapplications, based upon the false assumption thatanother area of security will cover it 3
  • 4. Cross Site Scripting (XSS)Cross-Site Scripting attack: A client executes a page containing script code that has been injected from other sources How can a malicious user perform a Cross Site Scripting attack? 4
  • 5. First scenario Web Application implementing Malicious user a Guestbook Malicious Input Page code Malicious user inserting a message, containing script code The script code is stored into DB table DB Storage Page the database A victim open the Message page Since no checks are Victim performed, the script code is sent to the browser as a message Guestbook Page The browser executes the 5
  • 6. Second scenario A Simple Search form Victim The victim unconsciously execute a link containing a malicious script code Simple Search server page write an error message… … but this error message contains the script code, that is executed by the browser Malicious code 6
  • 7. Key factors of XSS vulnerability the exploits are very simple to carry out, and no particular application knowledge or skill are required; the attacks may bypass perimeter defences (e.g. Firewalls), cryptography, digital signatures and site trusting; it may be very difficult for the victim to know which web application allowed the XSS attack; it may be very difficult for the developer to know which element of the web application allowed the XSS attack; evolution of hypertextual language characteristics and browser capabilities may make it possible new attack strategies and make vulnerable a web application which was considered invulnerable. 7
  • 8. Possible solutions To disable scripting language interpretation in browsers To install of a software proxy which intercepts malicious strings in input and/or output (Scott and Sharp, 2002) To introduce an input validation function immediately after every input statement contained in a Web page  To adopt this solution detection of vulnerabilities in source server script code is needed 8
  • 9. Detection and assessment of XSS vulnerabilitiesStatic and dynamic analysis of server pages are combined to detect and assess XSS vulnerabilities: Static analysis detects vulnerable pages and potentially vulnerable pages Dynamic analysis consists in the execution of a set of test cases reproducing XSS attacks 9
  • 10. Potential vulnerability of a server page A server page will be potentially XSS vulnerable if there are a variable v and two Input(v) and Output(v) nodes that are connected by a path on the CFG. nI <% nI ‘Read Message from input form Input 1 Message=request.form("txtMessage") 1 Message ‘Check for string “script” in Message 2 2 if instr(1,Message,“script")>0 then Message 3 response.write(“Forbidden”) … 4 else 3 . . . open DB connection . . . 10 Output 8 rs.open "Guestbook",conn,1,2,2 Message ‘Store Message into the DB … 9 rs.Addnew 10 rs("Message")=Message nF 11 rs.update nF end if %> 10
  • 11. Vulnerability of a server page A server page will be vulnerable if there are a variable v, and two Input(v) and Output(v) nodes, such that all the paths on the CFG leaving the Input(v) node reach the Output(v) node, being def-clear with respect to v. nI nI <% ‘Read Message from input form Input 1 Message=request.form("txtMessage") 1 Message . . . open DB connection . . . 5 rs.open "Guestbook",conn,1,2,2 Message … ‘Store Message into the DB 6 rs.Addnew 7 rs("Message")=Message Output 8 rs.update 7 Message nF %> … nF 11
  • 12. Invulnerability of a server pages A server page including an input data item that does not affect any output will be certainly invulnerable with respect to that input. nI nI <% ‘Read Message from input form Input Message 1 Message=request.form("txtMessage") 1 . . . open DB connection . . . 5 rs.open "Guestbook",conn,1,2,2 … ‘Store a constant string into the DB 6 rs.Addnew 7 rs("Message")=“One message received” nF 8 rs.update nF %> 12
  • 13. Vulnerability conditionsVulnerability predicates: A(v): There exists a path on the CFG between I and O nodes. B(v): The O node postdominates I node. C(v): Each path between I node and O node is a def-clear-path(obviously, B(v)=>A(v) and C(v)=>A(v) )Vulnerability conditions: PV) ∃v ∈ P: A(v) => P is potentially vulnerable with respect to v => P is potentially vulnerable V) ∃v ∈ P: B(v) AND C(v) => P is vulnerable with respect to v => P is vulnerable NV) ∃v ∈ P: NOT(A(v)) => P is not vulnerable with respect to v 13
  • 14. Examples (1) nI <% nI ‘Read Message from input form Input 1 Message=request.form("txtMessage") 1 Message ‘Check for string “script” in Message 2 2 if instr(1,Message,“script")>0 then Message 3 response.write(“Forbidden”) … 4 else3 . . . open DB connection . . . 10 Output 8 rs.open "Guestbook",conn,1,2,2 Message ‘Store Message into the DB … 9 rs.Addnew 10 rs("Message")=Message nF 11 rs.update The server page nF end if is potentially %> vulnerable with Predicate values Condition Input variable respect to the A B C V P NV   variable Message T F T F T F Message 14
  • 15. Examples (2) nI nI <% ‘Read Message from input form Input 1 Message=request.form("txtMessage") 1 Message . . . open DB connection . . . 5 rs.open "Guestbook",conn,1,2,2Message … ‘Store Message into the DB 6 rs.Addnew 7 rs("Message")=Message Output 8 rs.update 7 Message nF %> … The server page is vulnerable with nF respect to the Predicate values Condition Input variable variable Message A B C V P NV   T T T T T F Message 15
  • 16. Examples (3)nI nI <% ‘Read Message from input form Input Message 1 Message=request.form("txtMessage")1 . . . open DB connection . . . 5 rs.open "Guestbook",conn,1,2,2… ‘Store a constant string into the DB 6 rs.Addnew 7 rs("Message")=“One message received”nF 8 rs.update nF %> Predicate values Condition Input variable The server page A B C V P NV   is not vulnerable F F F F F T Message 16
  • 17. Static analysis1. Identify the input and output nodes of the CFG of the page P;2. Identify all paths leaving the input nodes on the CFG;3. For each path leaving an input(v) node and reaching an output(v) node, verify if the path is def-clear with respect to v;4. Evaluates A, B, and C predicates’ values with respect to v;5. Evaluate the vulnerability of page P, by the PV, NV, and V conditions. With reference to the second step of this process, in order to cope with the complexity of identifying all paths leaving the input nodes on the CFG, the analysis can be limited to a set of linearly independent paths extracted from the CFG. 17
  • 18. Dynamic analysis Tthe presence of a vulnerable page doesn’t imply that a XSS attack can be performed. To assess if a Web Application is actually vulnerable to XSS attacks, dynamic analysis may be performed. A vulnerability should be corrected and eliminated by the developer. The semantic of the source code of pages containing potential vulnerability should be analysed by the developer. A testing strategy involving the execution of a set of attack test cases must be followed 18
  • 19. Testing strategy (second scenario)FOR EACH vulnerable or potentially vulnerable page P of the Web Application FOR EACH input field I of page P causing vulnerability Define a set S of XSS attack strings FOR EACH s ∈ S EXECUTE server page P with input field I=s Check for attack consequences 19
  • 20. Testing strategy (first scenario)FOR EACH vulnerable or potentially vulnerable page P of the Web Application FOR EACH input field I of page P causing vulnerability Define a set S of XSS attack strings FOR EACH s ∈ S EXECUTE server page P with input field I= s FOR EACH test case T from the test suite EXECUTE test case T Check for attack consequences 20
  • 21. Case study Real world open source Web Applications implemented in PHP and ASP has been analysed An example: Snitz Forum, version 3.4.03 ( http://forum.snitz.com) Vulnerability situations has been detected using static analysis A vulnerability to XSS attacks of the second type has been confirmed by dynamic analysis 21
  • 22. An example An example of vulnerability is contained in the following source code:Response.Write “<input type=""text"" name=""Search"" size=""40"" value=""" & Request.QueryString("Search") & """><br />" & vbNewLineThis line of search.asp page contains a vulnerability: the value of aninput variable (Search) will be sent to the client browser with nochecks. The following test case perform a XSS attack redirecting ClientCookie values to a page of attacker’s server :“><script>location.URL=‘http://www.attackersite.com/attacker.cgi?’ + document.cookie) </script> 22
  • 23. An exampleThis vulnerability is also reported by Bugtraq web sites (http://www.securityfocus.com, http://msgs.securepoint.com/bugtraq/)and it has been corrected in the next version (3.4.04) of the forumResponse.Write ” "<td bgColor=""" &strPopUpTableColor & """ align=""left"" valign=""middle""><input type=""text"" name=""Search"" size=""40"" value="""& trim(ChkString(Request.QueryString("Search"),"display"))& """><br />" & vbNewLine & _ 23
  • 24. Conclusions A WA should be intrinsically secure, by adopting secure programming practices, in order to preserve its invulnerability as the execution environment changes. This paper proposed an approach for assessing the XSS vulnerability of an existing WA based on static and dynamic analysis of source code: Static analysis criteria have been defined to individuate vulnerable Web pages, while dynamic analysis strategies have been proposed to test the actual vulnerability of the Web Application including the vulnerable pages. 24
  • 25. Future works To support static analysis with automatic tools To integrate dynamic analysis with test case execution tools To assess the effectiveness of the approach with a wider set of applications 25