XSS Cross site scripting attacks

[RayYates]

FYI for anyone writing SQL queries, I'd like to offer the function below and get some feedback.

When ever you have global variables that will be passed to a SQL query you open up the posibility of someone altering the variable and inserting extra sql characters and statements into the query string.

In come cases it may be possible to get mySQL to "dump" the entire contents of the database to the screen.

'Select * FROM s01_Orders WHERE $ ' $ g.searchstring

If someone manages to insert code into g.searchstring, you may not get the results you expected.

Usually encodeentities() is used but in may cases it's overkill because it changes things in the string you may not want change. (for example you want to search for a string that contains '<')

PHP contains mysql_real_escape_string(string)
http://php.net/manual/en/function.my...ape-string.php

It renders hack attempts useless by altering the characters that would be inserted into your global variable.
\x00, \n, \r, \, ', " and \x1a.


A while ago I wrote a variation on the php function which seem very effective. I have not been able to get past it to insert code into a sql string.

<MvFUNCTION NAME="SqlEscape" PARAMETERS="string," STANDARDOUTPUTLEVEL="">
    <MvCOMMENT> MysqlEscape() \x00, \n, \r, \x1a, ", ', and \ . </MvCOMMENT>
    <MvFUNCRETURN VALUE="{ glosub(glosub(glosub(glosub(glosub(glosub(glosub(l.string
        ,asciichar(92),asciichar(92) $ asciichar(92))
        ,asciichar(0),asciichar(92) $ asciichar(0))
        ,asciichar(10),asciichar(92) $ asciichar(10))
        ,asciichar(13),asciichar(92) $ asciichar(13))
        ,asciichar(26),asciichar(92) $ asciichar(26))
        ,asciichar(34),asciichar(92) $ asciichar(34))
        ,asciichar(39),asciichar(92) $ asciichar(39))
    }">
</MvFUNCTION>

[eMediaSales]

Re: XSS Cross site scripting attacks

Hi Ray,

What you're describing is generally called SQL injection, which allows an attacker to generate an SQL statement different from what you intended. Considering the code above the more likely attack would be (theoretically) something like setting g.searchstring to: ' '; DELETE FROM s01_customers WHERE 1 or username = ' '

While SQL injection might be used to also insert data that you later display back in order to generate a cross site scripting (XSS) attack, the more likely method of doing XSS is by finding an input variable that is not sanitized before displaying back to the screen. For example, if you had this input for the above form, you'd be creating an XSS vulnerability:

<input type="text" name="searchstring" value="&mvt:global:searchstring;">

Miva Script provides methods to prevent both of these types of attacks:

SQL Injection: Use the Query Parameter syntax of Miva Script. Instead of:

<MvOPENVIEW ... QUERY = "{ 'Select * FROM s01_Orders WHERE $ ' $ g.searchstring }">

Use:

<MvOPENVIEW ... QUERY = "{ 'Select * FROM s01_Orders WHERE id = ?'}" FIELDS = "g.searchstring">

XSS protection:
Instead of:

<input type="text" name="searchstring" value="&mvt:global:searchstring;">

Use:

<input type="text" name="searchstring" value="&mvte:global:searchstring;">

*Note: see &mvt: versus &mvte: - the second format entitiy-encodes data before displaying back, preventing script tags from being output directly, so < and > are displayed as &lt; and &gt; preventing script execution.

Regards,
James

[wcw]

Re: XSS Cross site scripting attacks

Ray,

Also, remember it doesn't have to be something the customer enters. It could be one of your hidden inputs in the form, eg category_code. Always use the method James describes above. The only time you can use x = g.something is when you have complete control of what something is, e.g. prod.active = 1.

[RayYates]

Re: XSS Cross site scripting attacks

Thanks, I completely agree with both comments.

There are times when I assemble complex queries based on many conditionals (I always qualify the variables used). In those cases using the the FIELDS attribute, while possible, would add additional complexity as the fields list would also have to be constructed.

James in your example
; DELETE FROM s01_customers WHERE 1 or username = ' '

SqlEscape() would encode the single quotes ' ' and cause a sql syntax error. However, it would not catch the semicolon ;

I'll have to think about that...

[eMediaSales]

Re: XSS Cross site scripting attacks

Thanks, I completely agree with both comments.

There are times when I assemble complex queries based on many conditionals (I always qualify the variables used). In those cases using the the FIELDS attribute, while possible, would add additional complexity as the fields list would also have to be constructed.

Presumably you could build a dynamic query AND dynamic list of fields to be applied to that query. Not sure if I tried this, but the Miva SQL engine should still find the raw ? symbols, replace those with fields found in the l.fields variable in order.

<MvOPENVIEW NAME = "Merchant" VIEW = "XYZ" QUERY = "{ l.query }" FIELDS = "{ l.fields }">

Best,
James

[RayYates]

Re: XSS Cross site scripting attacks

Yes that is what I was referring to. FIELDS = "{ l.fields }

It could be done but franlky SqlEscape()ing the suspect variables is simpler. Other than the semi colon ; can you think of any other problem characters.

[kayakbabe]

Re: XSS Cross site scripting attacks

other problem characters are semi colons, the squiggle paranthesis , backslashes,
look for things in the where section of the query that
will always be true no matter what
like
'x'='x'
1=1
there should never be an instance where a real query would force itself to result in true no matter what. I often see these type of strings in the access logs when we're under an attack.
line breaks
line returns
single quotes
double quotes
semi colons
squiggle brackets
square brackets

if you must allow quotes and double quotes.. make sure you add the escape backslashes to them
o'conner should be o\'conner
make sure no double blackslashes are entered or the backslash is being escaped instead of the character you want to escape (if someone did enter \' ) if you just put in a \ before any ' without checking first you'd end up creating \\' and the ' would get through as unescaped.

one experience i had was with different codepage sets on the db and the website and webserver all had different code pages set.. what a nightmare! the foriegn characters broke any query. make sure they are the same.
I try to put a meta tag for the charset to match the charset of my database. that way any form fields entered will have the corret charset. Any values displayed on in the html the used to submit in a form (which would query the db) would be in the right code page. I've got everything as utf-8 now on the site where that was an issue.
<meta http-equiv="content-type" content="text/html; charset=UTF-8"/>

you can look for things like nested selects too.
if you strip out any semi colons that should cure that issue.
example

SELECT product_name FROM products
WHERE name = '%x%';
UPDATE members
SET email = '[email protected]'
WHERE email != null;
and name = '%y%';

the query will run if there is a way to insert it.

i'm sure I could think up some other things..

/* and */ to prevent commenting out parts of your query and allowing insertion of a different one.

[kayakbabe]

Re: XSS Cross site scripting attacks

there are a lot of things that can bust a query or allow access to data if the query isn't correct.

the best thing to do is sanitize the data before you put it in the sql query.
only allow the allowable characters possible. for example an email can only contain these characters.
abcdefghijklmnopqrstuvwxyz
ABCDEFGHIJKLMNOPQRSTUVWXYZ
[email protected]_+

if you know what is supposed to be entered.. then you can remove anything that isn't expected.

THIS IS WHY I KEEP ASKING FOR REGEXP on custom fields...!!!
then we can tell miva merchant exactly what is allowed to be entered in that field.

[kayakbabe]

Re: XSS Cross site scripting attacks

look at this
http://ferruh.mavituna.com/sql-injec...heatsheet-oku/
and that's just the tip of the iceberg.

much better to santize your data based upon expected and valid entry than just pass through just any old thing.

[RayYates]

Re: XSS Cross site scripting attacks

That's a good resource K.

I made a change for the semicolon ; and put up this page to test it. I can't find a way to insert anything that would result in a hacked query actually getting executed.

http://www.pcinet.com/samples/SqlEscape.mvc

If anyone else thinks of one let me know.

<MvFUNCTION NAME="SqlEscape" PARAMETERS="string " STANDARDOUTPUTLEVEL="">
    <MvCOMMENT> MysqlEscape() \x00, \n, \r, \x1a, ", ', ;,  and \ . </MvCOMMENT>
    <MvFUNCRETURN VALUE="{ glosub(glosub(glosub(glosub(glosub(glosub(glosub(glosub(l.string
    ,asciichar(92),asciichar(92) $ asciichar(92))
    ,asciichar(0),asciichar(92) $ asciichar(0))
    ,asciichar(10),asciichar(92) $ asciichar(10))
    ,asciichar(13),asciichar(92) $ asciichar(13))
    ,asciichar(26),asciichar(92) $ asciichar(26))
    ,asciichar(34),asciichar(92) $ asciichar(34))
    ,asciichar(39),asciichar(92) $ asciichar(39))
    ,';',asciichar(92) $ ';')
    }">
</MvFUNCTION>