Web Security | Web Hacking | Bug Bounty POC | Web Penetration Testing Tools

Monday, July 11, 2016

How to Disable Cross-site scripting (XSS) Attack

Hello
 i am Sajibe Kanti A Web Security Researcher.
So
Today i will Explain How TO Disable  XSS Attack
 on Your Web .
First step: recognize the signs and halt an XSS intrusion
Cross-site scripting (XSS) occurs when an attacker introduces malicious scripts to a dynamic form that allows the attacker to capture the private session information. In this article, Anand K. Sharma casts light on the areas vulnerable to XSS exploitation, explains how the user can protect himself, and details what the webmaster can do to secure a site from this type of malicious intrusion.
Most existing browsers are capable of interpreting and executing scripts -- created in such scripting languages as JavaScript, JScript, VBScript -- that are embedded in the Web-page downloads from the Web server. When an attacker introduces a malicious script to a dynamic form submitted by the user, a cross-site scripting (XSS) attack then occurs.
An XSS attack leads to undesirable effects. For example, the attacker gains the ability to capture the session information, peer into private user details such as ID, passwords, credit card information, home address and telephone number, social security/tax IDs, and so on. If the targeted Web site doesn't check for this type of malicious code, misuse of the user is probable.
To reduce the risk of having the script identified as malicious, the attacker might encode it with a different encoding method, such as HEX. With this alteration, the Web site displays the malicious content on the page as if the displayed information is the valid content from the site. If the Web application doesn't validate the input, all the attacker has to do is to coax the user to select the malicious hyperlink, after which the Web application collects confidential data from the user. This enables the attacker to capture the user's session and steal the user's credentials, redirect to a page on another Web site, and then insert code that can poison cookies, expose SSL connections, access restricted or private sites, or even trigger a number of such attacks.

A user's protection
A user can help reduce his susceptibility to an XSS-style attack in five significant ways:
  1. Disable scripting when it is not required.
  2. Do not trust links to other sites on e-mail or message boards. They may contain malicious code with damaging potential.
  3. Do not follow links from sites that lead to security-sensitive pages involving personal or business information unless you specifically trust them.
  4. Access any site involving sensitive information directly through its address and not through any third-party sites.
  5. Get a list of attacks and the sites and boards they happened on and be careful if you need to visit one of them.

Best practices for Web developers

What about the designers and maintainers of Web sites? you can reduce the problem with a variety of ways highlighted in this section, including a checklist at the end for Web developers.
First, validate the input. The following script accepts a parameter and reflects the same on the display.
Listing 5. A vulnerable script that accepts and reflects a parameter
#!/usr/bin/perl
        use CGI;

        my $var1 = CGI->new();
        my $parameter = $cgi->param('text');

        print $var1->header();
        print "parameter";
This piece of code is vulnerable to XSS attacks because no check is made to validate the input. The solution is to validate the input and HTML and escape the data before displaying the same. HTML escaping data means that non-alphanumeric characters are internally represented differently; for instance, with the lesser than (<) and greater than (>) signs represented as a string of characters (< and >).
Add input validation in this manner:
$parameter = ~ s/[^A-Za-z0-9 ]*/ /g;

This validation allows only alphanumeric and space characters and filters the rest. You can further strengthen validations by adding:
HTML::Entities::encode($parameter)
This snippet actually encodes HTML characters as HTML entity references. Characters like the less than sign< are encoded as "<" to help filter out such attacks. However, this is the not the end of the solution -- attacks can come in other forms.
You can add input validation to the script by inserting the following line of code before any output. This code eliminates any input other than letters, numbers, and spaces.
HTML::Entities::encode($text);
 
        $text =~ s/[^A-Za-z0-9 ]*/ /g;
This script is vulnerable to cross-site scripting attacks because it blindly prints out submitted form data. To get rid of this vulnerability, you can either perform input validation or ensure that user-submitted data is always HTML-escaped before displaying it.
With that in mind, TaintRequest automates the process of HTML escaping data. It always validates and HTML escapes the content before displaying or printing the data. (Perl has a feature like Taint mode built into it that can be used for such security checks.) This method ensures that any external data that flows into the program is not used directly for handling files and directories or for executing processes.Apache::TaintRequest is a very powerful check for preventing such attacks and making the application less vulnerable to XSS hazards.
To activate this feature, insert the following into the httpd.conf file.
PerlTaintCheck on
Do the following to ensure that the script uses Apache::TaintRequest:
use Apache::TaintRequest;
my $var1 = Apache::TaintRequest->new (Apache->request);
my $parameter = $var1->param('parameter');
$r->content_type("text/html");
$r->send_http_header;
$parameter =~ s/[^A-Za-z0-9 ]//; 
$r->print($parameter);
This piece of code takes up tainted data from the user, ensuring protection as it checks that the characters to be printed are only alphanumeric characters and spaces.
The following is a checklist of ways for webmasters and developers to prevent XSS attacks:

  • 1.Guarantee that the pages in the Web site return user inputs only after validating them for any malicious code.

2.
  • Filter Meta characters in the input while validating it. (This can be a major checkpoint to eliminate XSS attacks. Although it doesn't eliminate all XSS problems, it can alert Web maintainers to inadequacies in a site's security.)


3.
  • Do not completely trust Web sites that use HTTPS (Secure Sockets Layer) when it comes to XSS; HTTPS ensures secure connections, but processing of the data entered by the user is internal to the application. If the application has XSS holes, the attacker may send a malicious script that can still be executed by the application and lead to XSS intrusions.


4.
  • Convert all non-alphanumeric characters to HTML character entities before displaying the user input in search engines and forums.

5.
  • Use testing tools extensively during the design phase to eliminate such XSS holes in the application before it goes into use. (A best practices guide that stresses this is the philosophy of Extreme Programming.)

6.
  • Develop some standard or signing scripts with private and public keys that actually check to ascertain that the script introduced is really authenticated. (To implement things on such a large scale, the Internet rules have to be standardized to derive a common methodology with input from major players such as W3C.)



You Can See This video .

Thanks



 
 
 
 

No comments:

Post a Comment