Pages

Banner 468 x 60px

 
Showing posts with label xss. Show all posts
Showing posts with label xss. Show all posts

Monday, April 11

Cross Site Scripting

1 comments

Previously I wrote about the OWASP top 10 vulnerabilities. However my GURUJI asked me to post each topic individually.

Cross Site Scripting

Robert ‘rsnake’ Hensen is considered as Guru of XSS .Lets learn about what the XSS is

Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications which allow code injection by malicious web users into the web pages viewed by other users. Cross-site scripting holes in general can be seen as vulnerabilities which allow attackers to bypass security mechanisms. By finding clever ways of injecting malicious scripts into web pages an attacker can gain access privileges to sensitive page content, session cookies, and a variety of other objects.


XSS can be classified into three types


1. Non-Persistent

2. Persistant and

3. DOM based


Non-Persistent:


The non-persistent XSS are actually the most commons vulnerabilities that can be found on the Net. It's commonly named as "non-persistent" because it works on an immediate HTTP response from the victim website. It shows up when the webpage get the data provided by the attacker's client to automatically generate a result page for the attackers himself. Standing on this the attacker could provide some malicious code and try to make the server execute it in order to obtain some result.


Persistent:

A persistent XSS is also known as Stored XSS. The Persistent 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, where users are allowed to post.


DOM Based XSS:

The DOM-Based Cross-Site Scripting allow to an attacker to work not on a victim website but on a victim local machine.

The attacker creates a malicious site and sends to the victim. When the victim opens the vulnerable webpage or site on his machine the vulnerable page executes commands with the victim’s privileges and the attacker can easily gain control on the victim computer.


Finding the XSS Vulnerabilities


We most have tried finding an XSS hole by inserting a script like this

<script>alert('XSS')</script>

in Search fields and hoping for a box to popup saying XSS. But its not always the way to find a XSS vulnerability.

Some time we need to bypass the filters.

Here we will be using a JavaScript built in function called String.FromCharCode() that is used to encode/decode strings

For Example


<script>alert('XSS')</script>

and

<script>alert(String.fromCharCode(88, 83, 83))</script>


Note: 88 and 83 are ASCII values for X and S respectively. Visit this http://www.asciitable.com for more.

We have many ways to bypass filters. Some of are

site.com/search.php?q="><script>alert('Hyderbad Hacker')</script>

site.com/search.php?q="><script>alert("Hyderbad Hacker")</script>

site.com/search.php?q="><script>alert("Hyderbad Hacker");</script>

site.com/search.php?q="><script>alert(/Hyderbad Hacker");</script>

site.com/search.php?q=//"><script>alert(/Hyderbad Hacker/);</script>

site.com/search.php?q=abc<script>alert(/Hyderbad Hacker/);</script>

site.com/search.php?q=abc"><script>alert(/Hyderbad Hacker/);</script>

Securing XSS

To fix the XSS Vulnerability use htmlentities and

Sanitize all user input and escape special characters in your SQL Queries

For Example

The vulnerability code site looks like this

<span class="abc">Search result :</span>&nbsp;<strong><?php echo $_POST['vulnerability']; ?></strong>

To secure change this to

<span class="abc">Search result :</span>&nbsp;<strong><?php
if(isset($_POST['vulnerability']))

{ echo htmlentities($_POST['vulnerability']); } ?></strong>

use htmlspecialchars() function in PHP

other functions:

htmlentities() quotes

strip_tags()

--


I Hope You Like This Aritcle

Read more...

Saturday, April 9

OWASP Top Ten 2010 Web App Risks

2 comments
"OWASP was started in September 2000 with its mission to create an open source community where people could advance their knowledge about web application and web services security issues by either contributing their knowledge to the education of others or by learning about the topic from documentation and software produced by the project. At the time the web application security market was just emerging and certain vendors were pedaling some significant marketing claims around products that really only tested a small portion of the problems web applications were facing and service companies were marketing application security testing that was really left companies with a false sense of security."

The OWASP Top Ten List represents a broad consensus about what the most critical web application security flaws are, as determined by a variety of security experts from around the world. This information is very useful for determining if a web application being secure code. The OWASP survey has added extra weight as it has become a recommendation or required best practice from a number of highly regarded sources.The major companies all using the OWASP top 10 as a guide in their web application development.

The OWASP Top 10 web Application Risks as of 2010 list, are

1. Injection

Using almost any source of data, an attacker can send a simple piece of code that exploits the syntax of a targeted interpreter. Injection can lead to data loss, corruption, or complete host takeover. To prevent injection, the use of interpreters must separate untrusted data from commands and queries. An SQL call, for example, should use bind variables and avoid dynamic queries.
2. Cross Site Scripting

This has been one of the biggest security vulnerabilities on the web for some time now.It allows attackers to hijack a user's current session and either steal information or insert hostile content. Static and dynamic tools can find some XSS problems automatically, but because each application builds output pages as JavaScript, ActiveX, Flash, Silverlight, etc., automated detection is insufficient. Manual code review and penetration testing is needed. To prevent XSS, your application must keep untrusted data separate from active browser content.
3. Broken Authentication and Session Management

Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, session tokens, or exploit other implementation flaws to assume other users’ identities.
4. Insecure Direct Object References

This technique is used by an attacker who is already an authorized user. They simply change a parameter value to refer a system object to another object to gain access to other data and compromise it. All object references must have proper defenses by asking for authorization to specific resources and limiting indirect references to values authorized for the current user.
5. Cross-Site Request Forgery (CSRF)

In this attack, a forged HTTP request is used to trick victims into submitting them. Image tags, XSS, and many other techniques are used to trick users. Attackers use this to have hostile data manipulation performed on the victim's account. The simplest test for this vulnerability is to check each link and form to see if they contain an unpredictable token for each user so that attackers can't forge malicious requests. Unpredictable tokens should be included in the body or URL of each HTTP request and be unique for every user session and request.
6 Security Misconfiguration

Default accounts, unused pages, unpatched flaws, and directories can all be accessed by attackers to gain unauthorized access. Appropriate security hardening should be performed across the entire application stack to prevent this attack. Software (including ALL code libraries) should be kept up-to-date and unnecessary ports, services, pages, accounts, etc. should be removed.
7 Insecure Cryptographic Storage

Typically, hackers won't break through the cryptography directly. Instead they'll find keys, get cleartext copies of data, or find channels that automatically decrypt. To protect encrypted data, you must encrypt it in every area where it is stored long-term. Decrypted copies of the data and keys must be protected by requiring authorization
8 Failure to Restrict URL Access

This vulnerability is so easy to exploit that it must not be ignored. If the security hole exists, an attacker could simply modify a URL to access a privileged page and possibly escalate their privileges further. Developers must verify every single page and make sure external security mechanisms or code level protections are configured properly for each page. Policies should be highly configurable to minimize hard coded issues, and enforcement mechanisms should deny access by default by requiring specific grants for users.

9. Insufficient Transport Layer Protection

If user network traffic is not monitored properly, an attacker can expose data and steal accounts. A bad SSL setup can even facilitate MITM or phishing attacks. The easiest solution is to require SSL for the entire site or at least on private pages. The SSL provider should support only strong algorithms and the secure flag should be on all cookies.
10. Unvalidated Redirects and Forwards

Web apps that redirect or forward users to other URLs without proper validation of input data used to make such decisions may be vulnerable to attacks that redirect users to phishing or malware sites.
Read more...