Xss Basics

Cross-Site Scripting(XSS/CSS) [email protected] Technology team

What is Cross Site Scripting? 



Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications which allow code injection by malicious web users (attackers) into the web pages viewed by other users This involves an attacker attempting to manipulate a web application so that it embeds malicious script code in the page displayed to the user. The browser then processes the injected code as if it were legitimate content of the web page - with the corresponding security permissions. 

What is Cross Site Scripting? 



The heart of the issue is that if untrusted content can be introduced into a dynamic page, neither the server nor the client has enough information to recognize that this has happened and take protective actions. Used by attackers to bypass the same origin policy

Why it arises? 



Servers that generate static pages have full control over how the client will interpret the pages sent by the server. However, servers that generate dynamic pages do not have complete control over how their output is interpreted by the client XSS is only for dynamic web pages

When it arises? 

Cross-site scripting (XSS) occurs when an attacker introduces malicious scripts to a dynamic form that allows the attacker to capture the private session information.

How can a attacker identify it? Attacking the Application In order for a malicious user to conduct an XSS attack against the application, they first need to find a vector where all of the following are true:  The application is not validating input and  The application is not encoding output that contains untrusted

How user will be hijacked? Among the ways you can potentially expose your web browser to malicious scripts are these:  following untrusted links in web pages, email messages, or newsgroup postings  using interactive forms on an untrustworthy site  viewing dynamically generated pages that contain content developed by anyone but yourself

Why to solve this XSS? 



Security issue : It is the programmer's responsibility to ensure that his own code is secure against various attack vectors, some of which may be malicious in nature. User specific information (private data), cookies, the domain of browsing etc.., will be disclosed to the attacker

Who all should take care??    

Users Developers Administrators Browser vendors Should always take care of these XSS vulnerabilities

What are the different kinds of XSS?   

DOM-based Non-Persistent or reflected Persistent or non-reflected

DOM Based XSS 

 In DOM-based XSS, a

flawed browser-side application script copies the malicious code directly from the URL by accessing the DOM in the web page being displayed 

With DOM-based cross-site scripting vulnerabilities, the problem exists within a page's client-side script itself

DOM Based XSS 

Scenario 1.Attacker sends the URL of a maliciously constructed web page to user, using email or another mechanism. 2.user clicks on the link. 3.The malicious web page's java script opens a vulnerable HTML page installed locally on user's computer. 4.The vulnerable HTML page contains  java script  which executes in user's computer's local zone. 5.Attacker's malicious script now may run commands with the privileges user holds on her own computer.

DOM Based XSS Examples 

Consider, for example, the following HTML page (let’s say this is the content http://www.vulnerable.site/welcome.html):  <TITLE>Welcome! Hi <SCRIPT> var pos=document.URL.indexOf("name=")+5; document.write(document.URL.substring(pos,document.URL.length));
Welcome to our system   Normally, this HTML page would be used for welcoming the user, e.g.:   http://www.vulnerable.site/welcome.html?name=Joe However, a request such as:   http://www.vulnerable.site/welcome.html?name=   <script>alert(document.cookie)  would result in an XSS condition

DOM Based XSS Explanation The victim’s browser receives this link, sends an HTTP request to www.vulnerable.site, and receives the above (static!) HTML page. The victim’s browser then starts parsing this HTML into DOM. The DOM contains an object called document, which contains a property called URL, and this property is populated with the URL of the current page, as part of DOM creation. When the parser arrives to the Javascript code, it executes it and it modifies the raw HTML of the page. In this case, the code references document.URL, and so, a part of this string is embedded at parsing time in the HTML, which is then immediately parsed and the Javascript code found (alert(…)) is executed in the context of the same page, hence the XSS condition.

DOM Based XSS 

Soln <SCRIPT>   var pos=document.URL.indexOf("name=")+5;   var name=document.URL.substring(pos,document.URL.length);   if (name.match(/^[a-zA-Z0-9]$/))   {          document.write(name);   }   else   {          window.alert("Security error");   }

Non-Persistent or Reflected XSS 







The non-persistent or Type 1 cross-site scripting hole is also referred to as a reflected vulnerability (the most common type). These holes show up when data provided by a web client is used immediately by server-side scripts to generate a page of results for that user.  If unvalidated user-supplied data is included in the resulting page without HTML encoding, this will allow client-side code to be injected into the dynamic page. A classic example of this is in site search

Non-Persistent or Reflected XSS 

 This requires the attacker to persuade the victim to click on a prepared URL. The attacker conceals code in the variable parameters of this URL, which the vulnerable application receives server-side and embeds in the web page as apparent user names, e-mail addresses or search expressions

Non-Persistent or Reflected XSS Scenario  User often visits a particular website, which is hosted by say Reflexis. Reflexis website allows user to log in with a username/password pair and store sensitive information, such as billing information.  Attacker observes that Reflexis website contains a reflected XSS vulnerability.  Attacker crafts a URL to exploit the vulnerability, and sends user an email, making it look as if it came from Reflexis (i.e., the email is spoofed).  User visits the URL provided by attacker while logged into Reflexis website.  The malicious script embedded in the URL executes in user's browser, as if it came directly from Reflexis server. The script can be used to email user's session cookie to attacker. attacker can then use the session cookie to steal sensitive information available to user (authentication credentials, billing info, etc) without user's knowledge.

Persistent or Non Reflected XSS 



The persistent or Type 2 XSS vulnerability is also referred to as a stored or secondorder vulnerability, and it allows the most powerful kinds of attacks. A type 2 XSS vulnerability exists when data provided to a web application by a user is first stored persistently on the server (in a database, file system, or other location), and later displayed to users in a web page without being encoded using HTML entities. A classic example of this is with online message boards Persistent XSS can be more significant than other types because an attacker's malicious script is rendered more than once

Persistent or Non Reflected XSS 

Similar to reflected XSS, the server reflects the malicious code from the URL back to the browser as web content, but this time with a stop-over in the server database. The server may thus deliver the malicious code to other users, who have not clicked on a manipulated link - examples might include forum entries with embedded JavaScript. In this type of XSS, it is usually the attacker who only needs to click on a manipulated link once to upload malicious code onto the server

Persistent or Non Reflected XSS Scenario

 









Reflexis hosts a web site which allows users to post messages and other content to the site for later viewing by other members. Attacker notices that Reflexis website is vulnerable to a type 2 XSS attack. Attacker posts a message, controversial in nature, which may encourage many other users of the site to view it. Upon merely viewing the posted message, site users' session cookies or other credentials could be taken and sent to Attacker's webserver without their knowledge. Later, Attacker logs in as other site users and posts messages on their behalf....

Mistakes we do  

Trusting the User Unbounded Sizes 

If the size of the client data is unbounded and unchecked, an attacker can send as much data as she wants. This could be a security issue if there exists an as-yet- unknown buffer overrun in the database code called when invoking the SQL query



Using Direct User Input in SQL Statements (sql injection)

Any data received by the web application (via email, system logs, etc) that can be controlled by an attacker must be encoded prior to

What are the ways to solve those? 

Never Trust User Input!  





 All input is bad until proven otherwise Validating the user input data on both client (for DOM XSS) and server sides (remaining two). Mind you….Performance is rarely a problem when checking user input. Even if it is, no system is less reliably responsive than a hacked system You can either perform input validation or ensure that user-submitted data is always HTML-escaped before displaying it.

What are the ways to solve those? 

Data must be validated as it crosses the boundary between untrusted and trusted environments 

In other words, data is transferred from an untrusted source—a user—to a trusted source, the SQL database under application control.

We can replace special characters with corresponding char set values of the encoding

Steps to Mitigate XSS vulnerability 

   

Explicitly setting the character set encoding for each page generated by the web server Identifying special characters Encoding dynamic output elements Filtering specific characters in dynamic elements Examine cookies -- Before encoding & filtering we need to know about the special characters -- Encoding untrusted data has benefits over filtering untrusted data, including the preservation of visual appearance in the browser. This is important when special characters are considered acceptable.

Remember !!!!!! 







Step 1: Review your application code that generates output. Step 2: Determine whether output includes untrusted input parameters. Step 3: Determine the context in which the untrusted input is used as output. Step 4: Encode output.

Any proper way? From the security stand point assessing the developed code is imperative.  There should be a code review for the developed code while developing it self  But not always possible to that So ………  Write a tool (script) which will do the code review for the entire application 

Any proper way? Method and Approach Divide the method for approaching a code review exercise into several logical steps with specific objectives:  Dependency determination  Entry point identification  Threat mapping and vulnerability detection  Mitigation and countermeasures

Any proper way? 

Find out the dependencies in your application

Any proper way? Idea is!!!!!!!  Each and every entry point might be a cause for vulnerability  It is important to unearth where this variable goes (execution flow) and its impact on the application.

Example 

Check for an example in the following link which gives you a basic idea of how XSS happens

http://msdn.microsoft.com/en-us/library/a http://msdn.microsoft.com/en-us/library/

Assessing the application 





Try to fill the table for all the scenarios in your application Remember always any input data should be treated as input if no idea about it A use case scenario will be a simple page redirection or authentication Output (simple flow in the application) Contains Encoding

Use Case Scenario

Scenario Inputs

Input Trusted?

Scenario Outputs

Untruste d Input?

Requires Encoding

Method to Use

 

 

[Yes/No]

 

[Yes/No]

[Yes/No]

 

User’s hand book  







Disable scripting when it is not required. Do not trust links to other sites on e-mail or message boards. They may contain malicious code with damaging potential. Do not follow links from sites that lead to security-sensitive pages involving personal or business information unless you specifically trust them. Access any site involving sensitive information directly through its address and not through any third-party sites. Get a list of attacks and the sites and boards they happened on and be careful if you need to visit one of them.

Developer’s check list  









Guarantee that the pages in the Web site return user inputs only after validating them for any malicious code. Filter Meta characters in the input while validating it. (This can be a major checkpoint to eliminate XSS attacks. Although it doesn't eliminate all XSS problems, it can alert Web maintainers to inadequacies in a site's security.) Do not completely trust Web sites that use HTTPS (Secure Sockets Layer) when it comes to XSS; HTTPS ensures secure connections, but processing of the data entered by the user is internal to the application. If the application has XSS holes, the attacker may send a malicious script that can still be executed by the application and lead to XSS intrusions. Convert all non-alphanumeric characters to HTML character entities before displaying the user input in search engines and forums. Use testing tools extensively during the design phase to eliminate such XSS holes in the application before it goes into use. (A best practices guide that stresses this is the philosophy of Extreme Programming.) Develop some standard or signing scripts with private and public keys that actually check to ascertain that the script introduced is really authenticated. (To implement things on such a large scale, the Internet rules have to be standardized to derive a common methodology with input from major players such as W3C.)

What are the terms involved in it? Vulnerability - weakness  Same origin policy – two web pages are from same origin if they have same domain, port, protocol  Apache tainted request – for html escaping = Tainting + Apache::Request 

SQL Injection 



Custom web applications show many application developers do not fully understand the risk of SQL injection attacks and simple techniques used to prevent such attacks SQL injection is a basic attack used either to gain unauthorized access to a database or to retrieve information directly from the database



Fortunately, SQL injection attacks are easy to defend against with simple coding practices. However, every parameter passed to every dynamic SQL statement must be validated or bind variables must be used.

Types of sql injection 

There are four main categories of SQL Injection attacks against Oracle databases – 1. SQL Manipulation 2. Code Injection 3. Function Call Injection 4. Buffer Overflows

  

     

Solution:   The standard defenses for SQL injection attacks will also stop all function-based injection attacks.  The following steps will prevent all SQL injection attacks –   1.        Validate all string input and escape all single quotes 2.        Use bind variables instead of dynamically generated SQL 3.        Restrict access to standard database functions and procedures 4.        Restrict access to custom database stored procedures  

Important note I will update this PPT with more information Whenever I find some relevant information Please go through this mail for a sql demo by oracle http://st-curriculum.oracle.com/tutorial/SQLInjection/index.htm

References 



 



http://www.oreillynet.com/pub/a/sysadmin/2006/11/02/webapp_security_scans.htm -code review http://www.microsoft.com/mspress/books/sampchap/5612a.aspx - problems and solutions http://www.ibm.com/developerworks/ibm/library/wa-secxss/ - bank example http://msdn.microsoft.com/en-us/library/aa973813.aspx#anticross_sitescripting_topic4 – asp.net example http://www.cert.org/advisories/CA-2000-02.html - basics

– faq



http://www.cert.org/tech_tips/malicious_code_FAQ.html#FAQ



http://www.webappsec.org/projects/articles/071105.shtml - DOM based XSS http://en.wikipedia.org/wiki/Cross-site_scripting#Related_vulnerabilities - XSS basics









http://www.heise-online.co.uk/security/Web-application-security--/features/84511 - picture representation of various XSS http://www.cert.org/tech_tips/securing_browser/ - steps to secure your browser http://www.cert.org/tech_tips/malicious_code_mitigation.html - best practices for content developers