How to Cross Site Scripting (XSS) Attack Types

How to  Cross Site Scripting

XSS comes in three flavors of persistence, duration and damage. From XSSed they are:

Attackers intending to exploit cross-site scripting vulnerabilities must approach
each class of vulnerability differently.


                                                here is live demo.

 Type-0 attack

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

Type-1 attack

1. Alice often visits a particular website, which is hosted by Bob. Bob's website allows Alice to log in with a username/password pair and store sensitive information, such as billing information.
2. Mallory observes that Bob's website contains a reflected XSS vulnerability.
3. Mallory crafts a URL to exploit the vulnerability, and sends Alice an email, making it look as if it came from Bob (ie. the email is spoofed).
4. Alice visits the URL provided by Mallory while logged into Bob's website.
5. The malicious script embedded in the URL executes in Alice's browser, as if it came directly from Bob's server. The script steals sensitive information (authentication credentials, billing info, etc) and sends this to Mallory's web server without Alice's knowledge.
 
                              Get free ebook for hacking

Type-2 attack

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

        


   ....... Visit our FB page for recent hacking tricks .......

SQL Injection

SQL Injection   

        SQL Injection involves entering SQL code into web forms, eg. login fields, or into the browser address field, to access and manipulate the database behind the site, system or application.

When you enter text in the Username and Password fields of a login screen, the data you input is typically inserted into an SQL command. This command checks the data you've entered against the relevant table in the database. If your input matches table/row data, you're granted access (in the case of a login screen). If not, you're knocked back out.

The Simple SQL Injection Hack

In its simplest form, this is how the SQL Injection works. It's impossible to explain this without reverting to code for just a moment. Don't worry, it will all be over soon.

Suppose we enter the following string in a Username field:

' OR 1=1 double-dash-txt.png

The authorization SQL query that is run by the server, the command which must be satisfied to allow access, will be something along the lines of:

SELECT * FROM users WHERE username = ?USRTEXT '
AND password = ?PASSTEXT?

…where USRTEXT and PASSTEXT are what the user enters in the login fields of the web form.

So entering `OR 1=1 — as your username, could result in the following actually being run:

SELECT * FROM users WHERE username = ?' OR 1=1 — 'AND password = '?

Two things you need to know about this:
['] closes the [username] text field.

'double-dash-txt.png' is the SQL convention for Commenting code, and everything after Comment is ignored. So the actual routine now becomes:

SELECT * FROM users WHERE username = '' OR 1=1

1 is always equal to 1, last time I checked. So the authorization routine is now validated, and we are ushered in the front door to wreck havoc.

  Some simple injection techniques

   admin'—
    ') or ('a'='a
    ”) or (“a”=”a
    hi” or “a”=”a

How to Prevent From SQL Injection 

Use dynamic SQL only if absolutely necessary.
Dynamic SQL can almost always be replaced with prepared statements, parameterized queries, or stored procedures. For instance, instead of dynamic SQL, in Java you can use PreparedStatement() with bind variables, in .NET you can use parameterized queries, such as SqlCommand() or OleDbCommand() with bind variables, and in PHP you can use PDO with strongly typed parameterized queries (using bindParam()).
In addition to prepared statements, you can use stored procedures. Unlike prepared statements, stored procedures are kept in the database but both require first to define the SQL code, and then to pass parameters.

Escape user input.
Escaping user input is less effective than parameterized queries and stored procedures but if parameterized queries and stored procedures can't be used, escaping user input is still more than nothing. The exact syntax for escaping user input varies depending on the database, so you need to check your DB docs for the correct syntax and examples.


  Use automated test tools for SQL injections.
Even if developers follow the rules above and do their best to avoid dynamic queries with unsafe user input, you still need to have a procedure to confirm this compliance. There are automated test tools to check for SQL injections and there is no excuse for not using them to check all the code of your database applications.
One of the easiest tools to test SQL injections is the Firefox extension named SQL Inject ME. After you install the extension, the tool is available in the right-click context menu, as well as from Tools → Options