Home arrow Security arrow Page 6 - A Quick Look at Cross Site Scripting

Coding for our safety - Security

We may not be able to completely bulletproof our websites, but we can at least try to anticipate possible attacks and secure against them. Here is one you might not have heard of: cross site scripting. With just a bit of JavaScript, a malicious attacker can use it to cause all sorts of problems. To find out more about what it is, and how to prevent your website from becoming a victim, keep reading.

TABLE OF CONTENTS:
  1. A Quick Look at Cross Site Scripting
  2. What is Cross Site Scripting?
  3. Going deeper into JavaScript
  4. The hidden link
  5. Preventing Cross Site Scripting
  6. Coding for our safety
By: Alejandro Gervasio
Rating: starstarstarstarstar / 53
January 04, 2005

print this article
SEARCH DEV SHED

TOOLS YOU CAN USE

advertisement

Let’s define a simple function to prevent the querysting from being tampered with external code. The function “validateQueryString()” is the following:

<?php

function validateQueryString ( $queryString , $min=1,
                               $max=32 ) {
  if ( !preg_match ( "/^([a-zA-Z0-9]{".$min.",".$max."}=[a-zA-Z0-9]{".$min.",".$max."}&?)
+$/", $queryString ) ) {
    return false;
  }
  return true;
}

?>

Once we have defined this function, we call it this way:

<?php

$queryString = $_SERVER[‘QUERY_STRING’];
if ( !validateQueryString ( $queryString ) ) {
  header( ‘Location:errorpage.php’ );
}
else {
echo ‘Welcome to our site!’;
}

?>

Let’s break down the code to see it in detail.

The function performs pattern matching to the querystring passed as a parameter, checking to see if it matches the standard format of a querystring, including GET variable names that only contain the numbers 0-9 and valid letters either in lowercase or uppercase. Any other characters will be considered as invalid. Also, we have specified as a default value that variables can be from 1 to 32 characters long. If matches are not found, the function returns false. Otherwise, it will return true.

Next, we have performed validation on the querystring by calling the function. If it returns false -- that is, the querystring contains invalid characters -- the user will be taken to an error page, or whatever you like to do. If the function returns true, we just display a welcome message.

Of course, most of the time, we really know what variables to expect, so our validation function can be significantly simplified.

Given the previous URL,

http://www.yourdomain.com/welcomedir/
welcomepage.php?name=John

where the “name” variable is expected, we might write the new  “validateAlphanum()” function:

<?php

function validateAlphanum( $value , $min = 1 , $max =
                            32 )  {
  if ( !preg_match( "/^[a-zA-Z0-9]{".$min.",".$max."}
$/", $value ) ) {
    return false;
  }
  return true;
}

?>

and finally validate the value like this:

<?php

$name = $_GET[‘name’];
if ( !validateAlphanum ( $name ) ) {
  header( ‘Location:errorpage.php’ );
}
else {
  echo ‘Welcome to our site!’;
}
?>

The concept is the same as explained above. The only noticeable difference is that we’re taking in the “name” variable as the parameter for the “validateAlphanum()” function and checking if it contains only the allowed characters 0-9, a-z and A-Z. Anything else will be considered an invalid input.

If you’re a strong advocate of object oriented programming, as I am, we might easily include this function as a new method for an object that performs user data validation. Something similar to this:

<?php

$name = $_GET[‘name’];  
  // get variable value
$dv = &new dataValidator();  
  // instantiate new data
validator object
if ( !$dv->validateAlphanum( $name ) ) {  
  // execute validation method
  header( ‘Location:errorpage.php’ );
}
else {
  echo ‘Welcome to our site!’;
}

?>
 

Pretty simple, isn’t it?

In order to avoid Cross Site Scripting, several approaches can be taken, whether procedural or object-oriented programming is your personal taste.

In both cases, we’ve developed specific functions to validate querystrings and avoid tampered or unexpected user input data, demonstrating that Cross Site Scripting can be prevented easily with some help coming from our favorite server-side language.

Conclusion

As usually, dealing with user input data is a very sensitive issue, and Cross Site Scripting falls under this category. It is a serious problem that can be avoided with some simple validation techniques, as we have seen through this article.

Building up robust applications that won’t make poor assumptions about visitor’s input is definitely the correct way to prevent Cross Site Scripting attacks and other harmful techniques. Client environments must always be considered as a pretty unsafe and unknown territory. So, for the sake of your website’s sanity and yours, keep your eyes open.



 
 
>>> More Security Articles          >>> More By Alejandro Gervasio
 

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort
   

SECURITY ARTICLES

- Secure Your Business for Data Privacy Day
- Google Testing Security Fob Password Alterna...
- Security News Highlights Concerns
- Going to Extremes for Data Security
- Skipfish Website Vulnerability Scanner
- Critical Microsoft Visual Studio Security Pa...
- US Faces Tech Security Expert Deficit
- LAN Reconnaissance
- An Epilogue to Cryptography
- A Sequel to Cryptography
- An Introduction to Cryptography
- Security Overview
- Network Security Assessment
- Firewalls
- What’s behind the curtain? Part II

Developer Shed Affiliates

 


Dev Shed Tutorial Topics: