Web Applications Security XSS IT College, Andres Käver, 2017-2018, autumn semester Web: http://enos.Itcollege.ee/~akaver/WebSec Skype: akaver Email: akaver@itcollege.ee
TOP10 Web App Threats Injection (mostly SQL) Broken auth and session management Cross-Site Scripting (XSS) Insecure direct object reference Security misconfiguration Sensitive data exposure Missing function level access control Cross site request forgery (CSRF) Using components with known vulnerabilities Unvalidated redirects and forwards
XSS - Cross-Site Scripting Cross-site Scripting (XSS) refers to client-side code injection attack wherein an attacker can execute malicious scripts (malicious payload) into a legitimate website or web application. XSS is amongst the most rampant of web application vulnerabilities and occurs when a web application makes use of unvalidated or unencoded user input within the output it generates. While XSS can be taken advantage of within VBScript, ActiveX and Flash (although now considered legacy or even obsolete). Most widely abused is JavaScript – primarily because JavaScript is fundamental to most browsing experiences. An XSS vulnerability can only exist if the payload (malicious script) that the attacker inserts ultimately get parsed in the victim’s browser.
XSS – How it works In order to run malicious JavaScript code in a victim’s browser, an attacker must first find a way to inject a payload into a web page that the victim visits. Of course, an attacker could use social engineering techniques to convince a user to visit a vulnerable page with an injected JavaScript payload. In order for an XSS attack to take place the vulnerable website needs to directly include user input in its pages. An attacker can then insert a string that will be used within the web page and treated as code by the victim’s browser.
XSS – How it works print "<html>" print "<h1>Most recent comment</h1>" print database.latestComment print "</html>" The above page is vulnerable to XSS because an attacker could submit a comment that contains a malicious payload such as <script>doSomethingEvil();</script>. <html> <h1>Most recent comment</h1> <script>doSomethingEvil();</script> </html>
XSS – what can be achieved? The consequences of what an attacker can do with the ability to execute JavaScript on a web page may not immediately stand out, especially since browsers run JavaScript in a very tightly controlled environment and that JavaScript has limited access to the user’s operating system and the user’s files. BUT….
XSS – what can be achieved? Malicious JavaScript has access to all the same objects the rest of the web page has, including access to cookies. Cookies are often used to store session tokens, if an attacker can obtain a user’s session cookie, they can impersonate that user. JavaScript can read and make arbitrary modifications to the browser’s DOM (within the page that JavaScript is running). JavaScript can use XMLHttpRequest to send HTTP requests with arbitrary content to arbitrary destinations. JavaScript in modern browsers can leverage HTML5 APIs such as accessing a user’s geolocation, webcam, microphone and even the specific files from the user’s file system. While most of these APIs require user opt-in, XSS in conjunction with some clever social engineering can bring an attacker a long way.
XSS - Stored, Reflected, DOM XSS can be used in a range of ways to cause serious problems. The traditional (and dangerous) uses of XSS is the ability for an attacker to steal session cookies allowing an attacker to impersonate a victim. However, it is not just about stealing cookies, XSS has been used to wreak havoc on social networks, spread malware, website defacements, phish for credentials and even used in conjunction with social engineering techniques to escalate to more damaging attacks. Cross-site Scripting can be classified into three major categories — Stored XSS, Reflected XSS and DOM-based XSS.
XSS - Stored The most damaging type of XSS is Stored (Persistent XSS). Stored XSS attacks involves an attacker injecting a script (referred to as the payload) that is permanently stored (persisted) on the target application (for instance within a database). A classic example is a malicious script inserted by an attacker in a comment field on a blog or in a forum post. When a victim navigates to the affected web page in a browser, the XSS payload will be served as part of the web page (just like a legitimate comment would). This means that victims will inadvertently end-up executing the malicious script once the page is viewed in a browser.
XSS - Reflected The second, and by far most common type of XSS is Reflected XSS. Here, the attacker’s payload script has to be part of the request which is sent to the web server and reflected back in such a way that the HTTP response includes the payload from the HTTP request. Using Phishing emails and other social engineering techniques, the attacker lures the victim to inadvertently make a request to the server which contains the XSS payload and ends-up executing the script that gets reflected and executed inside the browser. Since Reflected XSS isn’t a persistent attack, the attacker needs to deliver the payload to each victim – social networks are often conveniently used for the dissemination of these attacks.
XSS - DOM-based DOM-based XSS is an advanced type of XSS attack which is made possible when the web application’s client side scripts write user provided data to the Document Object Model (DOM). The data is subsequently read from the DOM by the web application and outputted to the browser. If the data is incorrectly handled, an attacker can inject a payload, which will be stored as part of the DOM and executed when the data is read back from the DOM.
XSS – DOM-based The most dangerous part of this attack is often a client-side attack, and the attacker’s payload is never sent to the server. This makes it even more difficult to detect for Web Application Firewalls (WAFs) and security engineers analyzing the server’s logs since they will never even see the attack. Among various objects that make up the DOM, there are some objects in particular which an attacker can manipulate in order to generate the XSS condition. URL (document.URL), URL behind the hash (location.hash) Referrer (document.referrer).
XSS - Stored The Stored XSS condition is met when a website or web application stores user input, serves it back to other users when retrieving it at a later stage without validation before storage or before embedding stored content into HTML response pages. Stored XSS is less frequent than Non-Stored XSS, as the vulnerabilities which make it possible are less common and more difficult to find. Damage that Stored XSS can do is more devastating than the damage done by Non-Stored XSS – because once the payload is stored, it has the potential of infecting most of the visitors of the vulnerable web page
XSS - Stored
XSS – Stored, Consequences The consequences are vast, because the attack enables execution of arbitrary code, usually with elevated privileges – most home users still use the default “administrator” account and although latest Windows operating systems come with user access control and hardened browser policies, they are usually disabled in order to improve on the user experience. Typical goals of Persistent XSS attacks Cookie theft Data theft
XSS – Stored, Defending Server-side The best way to prevent Persistent XSS is to make sure that all user input is properly sanitized before it gets stored permanently on the web server, and as a second line of defense, make sure that the static content presented to users is also sanitized. As malicious scripts can be encoded in various ways, sanitization parsers should take encoding into consideration, as well as various ways to inject code, when searching for payloads in the content to be stored / served back.
XSS – Stored, Defending Client-side Users cannot take any particular actions in order to prevent such an attack, other than disabling JavaScript within their browser (disabling JavaScript is not seen as an adequate solution since several websites require it to function properly). Victims simply need to visit a vulnerable web page. Most victims of Persistent XSS attacks would be regular users of the vulnerable website, making it nearly impossible for them to prevent the attack from happening just by being weary about what they do within their browser. The only thing that can help in this case is using secure and up to date web browsers, with XSS filters turned on and hope for the best.
XSS – Reflected (non-persistent) The reflected XSS condition is met when a website or web application employs user input in HTML pages returned to the user’s browser, without validating the input first. With Non-Persistent cross-site scripting, malicious code is executed by the victim’s browser, and the payload is not stored anywhere; instead, it is returned as part of the response HTML that the server sends. Therefore, the victim is being tricked into sending malicious code to the vulnerable web application, which is then reflected back to the victim’s browser where the XSS payload executes.
XSS - Reflected
XSS - Reflected Research – find websites where user input is used in the response HTML page. Websites having search functionality and displaying the searched term on the HTML page returned with the results Websites with log on functionality, displaying the logged on user name on the returned HTML page Websites displaying information encoded in the HTTP headers, such as browser type and version Websites making use of DOM parameter values, such as document.URL
XSS - reflected Examples www.mywebsite.com/search.asp?term=my+search+term www.mywebsite.com/search.asp?term=<script>MaliciousFunction(...)</ script> www.mywebsite.com/logon.asp?user=Mary www.mywebsite.com/logon.asp?user=<script>MaliciousFunction(...)</sc ript>
XSS - reflected Social engineering SPAM email containing a crafted link SPAM email containing HTML code Malicious web pages containing a malicious URL ClickJacking Social media: messages / posts containing a malicious link XSS techniques: using Persistent (Stored) XSS, malicious links can be saved as part of forum posts / comments and reflected back to visiting users Other types of attacks: DNS rebinding – compromises the hosts file causing your browser to get redirected to malicious pages instead of the intended web page, compromising the wireless router, etc.
XSS - reflected Consequences Once the victim has clicked on the malicious link, and if the attack is successful, the payload will get executed in the victim’s context and call home to the attacker in order to communicate the results, as well as upload stolen data, etc. The consequences vary, because the attack enables execution of arbitrary code, usually with elevated privileges – most home users still use the default “administrator” account and although latest Windows operating systems come with user access control and hardened browser policies, they are usually disabled in order to improve on the user experience.
XSS - reflected Defending server-side The best way to prevent cross-site scripting is to make sure that the web application does not make use of user input in the return HTML pages, without validating it first. Validation implies verification of the user input to determine if the input is valid, according to its purpose. In case the validation functions find script tags, either in plain text or encoded, they should sanitize the input before it is passed on to the response HTML and make sure that the script is rendered harmless.
XSS - reflected Defending client-side Users should always be weary of what they click on; avoid playing seemingly harmless games, claiming random prizes or opening emails that don’t come from a trusted source. At the same time, users should avoid installing browser plugins which do not have a good reputation and those which are not really a necessity (such as toolbars), since these may make their browser vulnerable too. Using secure and up-to-date web browsers will also help users keep away from “victim” status.
XSS - DOM What is DOM The Document Object Model is a convention for representing and working with objects in an HTML document (as well as in other document types). Basically all HTML documents have an associated DOM, consisting of objects representing the document properties from the point of view of the browser. Whenever a script is executed client-side, the browser provides the code with the DOM of the HTML page where the script runs, thus, offering access to various properties of the page and their values, populated by the browser from its perspective.
XSS - DOM DOM XSS is a type of cross site scripting attack which relies on inappropriate handling, in the HTML page, of the data from its associated DOM. Among the objects in the DOM, there are several which the attacker can manipulate in order to generate the XSS condition, and the most popular, from this perspective, are document.url document.location document.referrer
XSS - DOM http://www.example.com/userdashboard.html?context=Mary <html> <head> <title>Custom Dashboard </title> ... </head> Main Dashboard for <script> var pos=document.URL.indexOf("context=")+8; document.write(document.URL.substring(pos,document.URL.length)); </script> </html>
XSS - DOM Malicious code Result Next, the browser finds the malicious code in the HTML body and executes it, thus finalizing the DOM XSS attack. In reality, the attacker would hide the contents of the payload in the URL using encoding so that it is not obvious that the URL contains a script. http://www.example.com/userdashboard.html?context=<script>SomeFunction(somevariable) http://www.example.com/userdashboard.html#context=<script>SomeFunction(somevariable) ... Main Dashboard for <script>SomeFunction(somevariable)</script>
XSS - DOM The HTML page is static, and there is no malicious script embedded into the page, as in the case of other types of XSS attacks The script code never gets to the server, if the “#” character is used; it is seen as fragment and the browser does not forward it further. Hence server-side attack detection tools will fail to detect this attack; In some cases, depending on the type of the URL, the payload might get to the server and it may be impossible to hide it.
XSS - DOM Defence The DOM XSS attack is difficult to detect by server-side attack detection and prevention tools, because usually the malicious payload does not get to the server and hence cannot be sanitized in the server-side code, like in the case of other XSS attacks. However, since the root of the problem still resides in the code of the page, this time the client-side code, the same sanitization and prevention techniques apply, but in this case the code review as well as the implementation of sanitization functionality needs to be performed on the client-side code.
XSS - DOM Defence Avoiding client-side sensitive actions such as rewriting or redirection, using client-side data Sanitization of the client-side code by inspecting and securely handling references to DOM objects that pose a threat, such as url, location and referrer, especially in cases when the DOM may be modified Using intrusion prevention systems which are able to inspect inbound URL parameters and prevent the inappropriate pages to be served.
XSS Practice in https://rangeforce.com Redeem code 2EIK4WASE
XSS THE END!
XSS