With the Cloud Penetrator you get full Cross Site Scripting XSS Scanning.
It is important to scan your site for XSS vulnerabilities and eliminate them as soon as possible.
You can also scan for Command Execution and Local file inclusions.
Improperly designed web sites and web applications are receptive to cross site script attacks, whereby scripts are bolted in the domain of the web site rather than just locally on the machine. Essentially, a cross-site scripting attack consists of a malicious user getting his code to run on someone else´s web page in that person´s browser in the context of the web server. An end result of cross-site scripting could be a malicious script deleting a user´s account off the server or making purchases for him. Cross-site scripting attacks allow for cookies to be read or set, and browser plug-ins scripts, native code or even controls can be started and can run unfrosted data. With this code running, user input such as a credit card number, home address, or other sensitive information can be captured and therefore compromised. Any browser with a scripting engine can be compromised through this type of attack, and any web server using HTML forms is at risk for being open to this.
One way to check for cross-site scripting vulnerability is to fill out a form with some easily recognizable data (for example, 1111111111 or AAAAAAAA) in all fields. On saving or manipulating the form, check the form source for this data being stored in hidden fields or other areas. Appending a parameter to your URL (?cmd=AAAAAAAA or ;AAAAAAAAA), hitting Enter, and then searching the resulting source can also tell you if the parameter is attack. Other holes are created through assumptions, such as what domain the code is coming from. In these cases, the URL standards need to be carefully followed, and the IE functions need to be used to determine what domain is being referenced rather than going off and writing your own functions.
The real problem at the heart of any cross-site scripting attack is that the Web page displays data that has not been validated by the server. This risk is created through poor coding and poor architecture of the application. Cross-site scripting is most usually a shared data problem because the data is provided by a malicious user. The typical points of attack are: Through query strings issued to the database, by way of data posted to the server, through URLs or pieces of URLs cookies, or other user-supplied data that is persisted in some way (usually in the database)
To exploit a server, all that a malicious user needs is for one server inside the firewall to no check a field in a form for special characters. The same precautions that protect the application and user from other attacks also work here. Data should be verified as safe before using it, by escaping, filtering input, and filtering the output if necessary. Again, many of the vulnerabilities can be eliminated with proper escaping of input and particular characters.
If all data is handled properly through verification, escaping and filtering cross-site scripting is generally not a problem. Tools for testing cross-site scripting are: character viewing and generating tools, network monitoring tools. Reliable methods to avoid cross-site scripting vulnerabilities needs the encryption of all special characters used while coding HTML in potentially malicious data. This prevention method is usually applied right before the presentation of a client-side script or the web applications, and several programming languages have libraries or built-in functions which supply this encryption (in this context, also known as escaping or quoting).
One of the problems while dealing with cross site scripting vulnerabilities is that every situation is different. Each time, the method used to hack the system varies and thus the issues. For example, in the case of user input, the src attribute of a hyperlink, cgi.escape() would be enough to put things upside down. There are several ways to fix these issues. However, one of the drawbacks of this fixing is that users will not be able to embed malicious HTML into pages. This is because HTML standards do not have scripts to perform such actions.
|➤ Related pages|
Powerful UTM Firewall, Vulnerability Scanner, WiFi Penetration Testing software
SecPoint is specialized to deliver the best IT security solutions and products.