Pattern Recognition and Applications Lab Integrity attacks (from data to code): Cross-site Scripting - XSS Igino Corona igino.corona (at) diee.unica.it Computer Security April 12, 2018 Department of Electrical and Electronic Engineering University of Cagliari, Italy 1 Let s play with OWASP Mutillidae II Very useful training application by OWASP 2
Reflected XSS 3 Reflected XSS The input of parameter PathToDocument is present in the web page output 4
Reflected XSS Put the classical test string as input for PathToDocument: <script>alert('vulnerable')</script> Such string is reflected as is, in the page output where is interpreted by the browser as HTML and then JavaScript code 5 Reflected XSS In a real-world attack, reflected XSS may be used to stealthily collect confidential information about a user of the vulnerable site perform impersonation, execute an exploit on the victim s browser the attacker can execute arbitrary JavaScript code with the privileges given by the victim s browser to the vulnerable website To this end, a targeted phishing email may be crafted using athe identity of the vulnerable site (es. Google) to induce the user to click on the malicious link, e.g., www.google.com/mutillidae/index.php?page=documentviewer.php&pathtodocument=%3c%73%63%72%69%70%74 %3e%61%6c%65%72%74%28%27%76%75%6c%6e%65%72 %61%62%6c%65%27%29%3c%2f%73%63%72%69%70%74% 3e 6
Reflected XSS https://www.google.com /mutillidae/index.php?p age=documentviewer.php&pathtodoc ument=%3c%73%63% 72%69%70%74%3e%6 1%6c%65%72%74%28 %27%76%75%6c%6e %65%72%61%62%6c %65%27%29%3c%2f% 73%63%72%69%70%7 4%3e 7 Persistent (Stored) XSS 8
Persistent (Stored) XSS Test code tries to output document cookies in a window 9 Persistent (Stored) XSS We inserted HTML code that executes JavaScript code within a blog entry Such code is stored as is within the database outputted as is when blog entries are displayed (by any user) 10
Persistent XSS In a real-world attack, persistent XSS may be used to stealthily collect confidential information about any user of the vulnerable site, including admin users perform impersonation, execute an exploit on the victim s browser the attacker can execute arbitrary JavaScript code with the privileges given by the victim s browser to the vulnerable website More powerful than reflected XSS Typically, no need for phishing emails The attacker can add arbitrary code within the vulnerable site 11 Persistent XSS Vulnerable admin webpages are expecially useful for cyber criminals https://blog.sucuri.net/2016/01/security-advisory-stored-xssin-magento.html 12
Client-side XSS In this case, vulnerable code is @client-side applications Typically, leverages on vulnerabilities within JavaScript code executed by web browsers We experiment with a special case, using DOM injection 13 Client-side XSS We see that a username input is outputted in the page 14
Client-side XSS Let s look @ the source code It seems that username input is appended (by the server application) to the string "This password is for The string is then put through JavaScript code into the DOM element with id idusernameinput <script> try{ document.getelementbyid("idusernameinput").innerhtml = "This password is for anonymous"; } catch(e) { alert("error: " + e.message); }// end catch </script> <tr style="text-align: center;"> <td id="idusernameinput" HTMLEventReflectedXSSExecutionPoint="1" class="label"></td> </tr> 15 Server-side XSS The attacker may try to directly inject (add) JavaScript code exploiting a vulnerable routine @ server-side: username=anonymous";alert(document.cookie);var a= <script> try{ document.getelementbyid("idusernameinput").innerhtml = "This password is for anonymous";alert(document.cookie);var a=""; } catch(e) { alert("error: " + e.message); }// end catch </script> 16
Client-side XSS HTML input is not filtered by JavaScript code The attacker may also exploit such client-side vulnerability to inject HTML code through the DOM: username=google\<img src=\"https://www.google.it/logos/doodles/2016/antoni-vanleeuwenhoeks-384th-birthday-5116176595156992-hp.gif\"/\>";var a=" <script> try{ document.getelementbyid("idusernameinput").innerhtml = "This password is for username google\<img src=\"https://www.google.it/logos/doodles/2016/antoni-van-leeuwenhoeks-384th-birthday- 5116176595156992-hp.gif\"/\>";var a=""; } catch(e) { alert("error: " + e.message); }// end catch </script> 17 Type: Persistent (stored) Malicious input data is stored and comes from a database Reflected Malicious input data comes directly from the client (user) and is reflected in the webpage output Location of vulnerable code: Server-side Web application code (e.g., PHP) executed @ server-side Client-side Web application code (typically JavaScript) executed @ clientside 18
Targets: HTML/JavaScript code generation routines of client- and server-side applications Interpreter: JavaScript engine @ client-side (browser) An insecure handling of input data by web application HTML/JS generator routines, allows the attacker to convert input data into (arbitrary) JavaScript code Flash Silverlight PDF Reader Images JavaScript application CSS HTTP(S) Client HTML/JS code generation HTML Client-side XSS Application HTML/JS code generation HTTP(S) server Database Server-side XSS 19 Many TOP 10 attacks violate integrity TOP 10 Threat Security Violation A1:2017 Injection Integrity (DataàCode) A2:2017 - Broken Authentication Authentication A3:2017 Sensitive Data Exposure Confidentiality A4:2017 - XML External Entities (XXE) Integrity (DataàCode) A5:2017 - Broken Access Control Access Control A6:2017 - Security Misconfiguration Any A7:2017 - Cross-Site Scripting (XSS) Integrity (DataàCode) A8:2017 - Insecure Deserialization Integrity (DataàCode) A9:2017 - Using Components with Known Vulnerabilities Any A10:2017 - Insufficient Logging & Monitoring Monitoring
Take aways We have seen different data->code attack instances that lead to (system) integrity violations SQL Injection Cross-site Scripting Protecting web applications against data->code attacks require one to: Identify ALL involved interpreters in the web application From HTTP(S) level to DB interfaces and browser plugins For each interpreter use a safe API that prevents data from becoming code accurately determine the functioning of the application for ANY data input (expected or unexpected) Take aways Key security functionalities Authentication https://www.owasp.org/index.php/authentication_cheat_sheet Access Control https://www.owasp.org/index.php/access_control_cheat_sheet Authentication and access control are the key components to support Availability Integrity Confidentiality (strictly coupled!) https://www.owasp.org/index.php/top_10-2017_a3-sensitive_data_exposure Monitoring and response are necessary to mitigate (unavoidable) security violations self-monitoring and monitoring data protection
Are you interested in cybersecurity? The Cybersecurity Market is HUGE Thesis proposals include Botnet detection DNS traffic analysis @ ISP premises /en/fluxbuster Web intrusion detection systems /en/sustorid Phishing detection https://www.pluribus-one.it/?id=44 Android malware detection /en/androidpraguarddataset Adversarial Machine Learning - for computer security https://sec-ml.pluribus-one.it/ Many successful stories, latest ones (with my supervision) Simone Moro Android Vulnware /en/node/1198 Matteo Contini Phishing Detection https://tesi.clusit.it/vincitori.php