sitewatch safe web

Making the internet safe since 1986

Big enterprises thanks us for our work to help secure their web applications. Even large software development companies have problems with web security, and Sitewatch has the solution for you company the secure you webapplication.


Sitewatch has the industrial strength to help Large Enterprises and small enterprises such as the big igaming, casino and web hosting corporations. Sitewatch is an active participant of the “Web Anti-Exploit Program”. Our company is listed on every quarter in the Hall of Fame.

Sitewatch is helping the world of web applications to be more secure and safe. One of the vulnerability we found and are famous for is CVE-2011-0049, which is in the top 500 most dangerous vulnerabilities of all time.

safeI am happy to announce that Sitewatch is on the Google Security Hall of fame for two periods in a row!  There are 5 others that also accomplished this same feet. I am curious what the next period will hold.  I know one thing for sure, Sitewatch will be on the Hall of Fame next period.


Sitewatch is helping secure the world of open source by testing projects like Pligg.

There are many reasons why a company like yours should use this service. We provide with our special and long engaged team a clean, safe and secure solution.

Thousands  of people has used our service before.


Sitewatch has uncovered 16 reflective XSS vulnerablites affecting various wordperss themes.   Some of these themes are available to users,  which negatively impacts this service.    Wordpress themes are vulnerable to XSS because the platform doesn’t enforce security.  Drupal on the other hand tries to be secure by default although this isn’t perfect I think this is a much better approach to security.  You can’t assume developers on your platform are gong to understand all of the strange rules for XSS,  so Sitewatch is trying to help.   If you look at the PoC’s you’ll see common XSS vectors include $_SERVER[‘PHP_SELF’] and XSS in dom events.   The DOM event based XSS is interesting,  in my recent paper Bypassing IE’s XSS filter I showed that IE doesn’t protect its DOM events from XSS,  so these attacks will just work without modification.

By default Internet Explorer 9 has a security system to help prevent Reflective XSS attacks. There are well known shortfalls of this system, most notably that it does not attempt to address DOM based XSS or Stored XSS. This security system is built on an arbitrary philosophy which only accounts for the most straight forward of reflective XSS attacks[1]. This paper is covering three attack patterns that undermine Internet Explorer’s ability to prevent Reflective XSS. These are general attack patterns that are independent of Web Application platform.

sslXSS is not an input validation problem, its an output validation problem. If you perform the same input validation on all input indiscriminately you’ll still have problems with XSS. For instance if you encode or strip all greaterthan < and lessthan > characters for every input variable you can still have problems with XSS. This is because XSS is highly dependent on where the variable is being printed to the page.

secureLets say we have a web application that is assigning a JavaScript variable based on GET variable. This JavaScript will not execute the alert, instead it is being assigned to the variable x.A partial solution to this problem is to encode all quote marks as well. For instance in PHP you can use htmlspecialchars($var,ENT_QUTOES); to accomplish this.

But here is the real kicker, even this function can’t stop ALL XSS. You can still run into problems with DOM based xss and XSS via event handlers.

This is becuase the variable will go though a decoding process by the browser before it is executed.

In this case, when a user clicks on the following link  alert(123) is not going to be exceuted.   Instead it is a pramater to a JavaScript function that was supplied by a GET variable.

However,  even if the quote marks are encoded using html encoding.  The browser will perform an HTML Decode prior to executing the onclick event.   There for the following alert(123) will be executed!

This is due to the fact that the browser interprates this code as:

In this representation of the code you can see that the attacker was able to break out of the single quote marks and execute an arbitrary javascript payload.

So whats the real solution? Test your code! Use a free vulnerability scanning service like Sitewatch!