*modified

function xssSqlClean()
{
    // Function to check for SQL Injections and XSS Attacks. Will terminate execution if found
    foreach ( $_REQUEST as $key => $data ) {
        $data = strtolower( $data );
        
        if ( strpos( $data, "base64_" ) !== false )
            die( "Possible XSS / SQL Injection Attack" );
        
        if ( strpos( $data, "union" ) !== false && strpos( $data, "select" ) !== false )
            die( "Possible XSS / SQL Injection Attack" );
    }
}

hilaryiwens05:

    // Function to check for SQL Injections and XSS Attacks. Will terminate execution if found
    foreach ( $_REQUEST as $key => $data ) {
        $data = strtolower( $data );
        
        if ( strpos( $data, "base64_" ) !== false )
            die( "Possible XSS / SQL Injection Attack" );
        
        if ( strpos( $data, "union" ) !== false && strpos( $data, "select" ) !== false )
            die( "Possible XSS / SQL Injection Attack" );
    }
}

It's supposed to check for SQL Injection Attacks and terminate them right? but from what I can read from the source code, I don't see how it even remotely does that.

ahhhh this one big pass me ooo, i was doing a research about XSS Attacks my clients do hav on their host and i came across this. can anybody throw more light on this

Fulaman198:


It's supposed to check for SQL Injection Attacks and terminate them right? but from what I can read from the source code, I don't see how it even remotely does that.

hilaryiwens05:
ahhhh this one big pass me ooo, i was doing a research about XSS Attacks my clients do hav on their host and i came across this. can anybody throw more light on this

This article is pretty much spot on:

http://en.wikipedia.org/wiki/Cross-site_scripting

hilaryiwens05:
*modified

function xssSqlClean()
{
    // Function to check for SQL Injections and XSS Attacks. Will terminate execution if found
    foreach ( $_REQUEST as $key => $data ) {
        $data = strtolower( $data );
        
        if ( strpos( $data, "base64_" ) !== false )
            die( "Possible XSS / SQL Injection Attack" );
        
        if ( strpos( $data, "union" ) !== false && strpos( $data, "select" ) !== false )
            die( "Possible XSS / SQL Injection Attack" );
    }
}

You're checking (user) input for 'base64_' refs or 'union' and 'select' statements... for db exploit

this should be used in a simple php form request and ($_POST)

AAinEqGuinea:


You're checking (user) input for 'base64_' refs or 'union' and 'select' statements... for db exploit

this should be used in a simple php form request and ($_POST)

I guess in his if statement too, he's also calling for the function "die" if the user output matches the argument listed in the input for base64_. This is php right? is die() just a cout (meaning to output or print)?

Fulaman198:


I guess in his if statement too, he's also calling for the function "die" if the user output matches the argument listed in the input for base64_. This is php right? is die() just a cout (meaning to output or print)?

Yea, php

Yea, a php die message. You're on the right path, die is more like a dying error.message when /if handling exceptions or a condition to terminate than cout which continues runtime.

The first if checks for the existence of base64 encoding in your REQUEST array by checking for the string position of the word combination 'base64'. This is one of the common methods of XSS attack as the resource is provided externally via a base64 text encoded url (for example a .png image can be encoded as a base64 text and decoded back to it's initial status by calling this PHP function $imgdata = base64_decode($encoded_string); as so). Thus the external code (JavaScript payload) will be executed when the DOM initializes the object element. So by check through the request array for the existence of base64 you might be able to tell that an CSS attack is being attempted.

The second if Check for the words SELECT and UNION in REQUEST data url, it is common to use these SQL statements for SQL injection. Although It is not limited to only this two alot of other scenarios still exist. Wherever you got this code from I am going to assume that they were just illustrated for educational purpose. As it is barely bullet proof against SQL injection or XSS attacks.

Let's consider nairaland programming forum for example, I just used the word SELECT and UNION in this post. Running your script in the back-end will identify this post as a possible SQL injection attack and the web page will die (so to speak) whereas it is not an injection attack but merely a reply to your post. So in some cases using the codes improperly might yield unwanted results. Other cases you would have to use other SQL injection prevention (rather than Detection) methods such as tag stripping to say the minimum. I hope this helps.

AAinEqGuinea:


Yea, php

Yea, a php die message. You're on the right path, die is more like a dying error.message when /if handling exceptions or a condition to terminate than cout which continues runtime.

Good stuff, thanks