Suggestion for Mainfile.php

Posted: Wed Jun 16, 2004 5:52 am

This evening I was checking out the mainfile.php (can't recall why) but I stumbled upon some repetitive loops near the top using foreach statements to check on variable values for legitimate html characters, I am not sure if some people don't know but the $_REQUEST superglobal is the $_GET, $_POST and $_COOKIE arrays all in one (From 4.1.0 - 4.3.0, it included the $_FILES Superglobal as well). Using this logic, I recrafted some of the code.

Here is the original code followed by my proposed change(s)

Code:




foreach ($_GET as $secvalue) {


    if ((eregi("<[^>]*script*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*object*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*iframe*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*applet*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*meta*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*style*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*form*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*img*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*onmouseover*\"?[^>]*>", $secvalue)) ||


   (eregi("\([^>]*\"?[^)]*\)", $secvalue)) ||


   (eregi("\"", $secvalue))) {


   die ("<center><img src=images/logo.gif><br><br><b>The html tags you attempted to use are not allowed</b><br><br>[ <a href=\"javascript:history.go(-1)\"><b>Go Back</b></a> ]");


    }


}





foreach ($HTTP_GET_VARS as $secvalue) { 


    if ((eregi("<[^>]*script*\"?[^>]*>", $secvalue)) || 


   (eregi("<[^>]*object*\"?[^>]*>", $secvalue)) || 


   (eregi("<[^>]*iframe*\"?[^>]*>", $secvalue)) || 


   (eregi("<[^>]*applet*\"?[^>]*>", $secvalue)) || 


   (eregi("<[^>]*meta*\"?[^>]*>", $secvalue)) || 


   (eregi("<[^>]*style*\"?[^>]*>", $secvalue)) || 


   (eregi("<[^>]*form*\"?[^>]*>", $secvalue)) || 


   (eregi("<[^>]*img*\"?[^>]*>", $secvalue)) || 


   (eregi("<[^>]*onmouseover*\"?[^>]*>", $secvalue)) || 


   (eregi("\"", $secvalue))) {


   die ("<center><img src=images/logo.gif><br><br><b>The html tags you attempted to use are not allowed</b><br><br>[ <a href=\"javascript:history.go(-1)\"><b>Go Back</b></a> ]");


    }


}





foreach ($_POST as $secvalue) {


    if ((eregi("<[^>]*onmouseover*\"?[^>]*>", $secvalue)) ||   (eregi("<[^>]*script*\"?[^>]*>", $secvalue)) ||   (eregi("<[^>]*style*\"?[^>]*>", $secvalue))) {


        die ("<center><img src=images/logo.gif><br><br><b>The html tags you attempted to use are not allowed</b><br><br>[ <a href=\"javascript:history.go(-1)\"><b>Go Back</b></a> ]");


    }


}

The if (isset($_REQUEST)) { ensures that they are using a version of php 4.1.0 or newer (Introduced in 4.1.0)

Code:




if (isset($_REQUEST)) {


     foreach ($_REQUEST as $secvalue) {


          if ((eregi("<[^>]*script*\"?[^>]*>", $secvalue)) ||


      (eregi("<[^>]*object*\"?[^>]*>", $secvalue)) ||


     (eregi("<[^>]*iframe*\"?[^>]*>", $secvalue)) ||


     (eregi("<[^>]*applet*\"?[^>]*>", $secvalue)) ||


     (eregi("<[^>]*meta*\"?[^>]*>", $secvalue)) ||


     (eregi("<[^>]*style*\"?[^>]*>", $secvalue)) ||


     (eregi("<[^>]*form*\"?[^>]*>", $secvalue)) ||


     (eregi("<[^>]*img*\"?[^>]*>", $secvalue)) ||


     (eregi("<[^>]*onmouseover*\"?[^>]*>", $secvalue)) ||


     (eregi("\([^>]*\"?[^)]*\)", $secvalue)) ||


     (eregi("\"", $secvalue))) {


          die ("<center><img src=images/logo.gif><br><br><b>The html tags you attempted to use are not allowed</b><br><br>[ <a href=\"javascript:history.go(-1)\"><b>Go Back</b></a> ]");


          }


     }


} else {


     foreach ($_GET as $secvalue) {


          if ((eregi("<[^>]*script*\"?[^>]*>", $secvalue)) ||


      (eregi("<[^>]*object*\"?[^>]*>", $secvalue)) ||


     (eregi("<[^>]*iframe*\"?[^>]*>", $secvalue)) ||


     (eregi("<[^>]*applet*\"?[^>]*>", $secvalue)) ||


     (eregi("<[^>]*meta*\"?[^>]*>", $secvalue)) ||


     (eregi("<[^>]*style*\"?[^>]*>", $secvalue)) ||


     (eregi("<[^>]*form*\"?[^>]*>", $secvalue)) ||


     (eregi("<[^>]*img*\"?[^>]*>", $secvalue)) ||


     (eregi("<[^>]*onmouseover*\"?[^>]*>", $secvalue)) ||


     (eregi("\([^>]*\"?[^)]*\)", $secvalue)) ||


     (eregi("\"", $secvalue))) {


          die ("<center><img src=images/logo.gif><br><br><b>The html tags you attempted to use are not allowed</b><br><br>[ <a href=\"javascript:history.go(-1)\"><b>Go Back</b></a> ]");


          }


     }





     foreach ($HTTP_GET_VARS as $secvalue) { 


           if ((eregi("<[^>]*script*\"?[^>]*>", $secvalue)) || 


     (eregi("<[^>]*object*\"?[^>]*>", $secvalue)) || 


     (eregi("<[^>]*iframe*\"?[^>]*>", $secvalue)) || 


     (eregi("<[^>]*applet*\"?[^>]*>", $secvalue)) || 


     (eregi("<[^>]*meta*\"?[^>]*>", $secvalue)) || 


     (eregi("<[^>]*style*\"?[^>]*>", $secvalue)) || 


     (eregi("<[^>]*form*\"?[^>]*>", $secvalue)) || 


     (eregi("<[^>]*img*\"?[^>]*>", $secvalue)) || 


     (eregi("<[^>]*onmouseover*\"?[^>]*>", $secvalue)) || 


     (eregi("\"", $secvalue))) {


          die ("<center><img src=images/logo.gif><br><br><b>The html tags you attempted to use are not allowed</b><br><br>[ <a href=\"javascript:history.go(-1)\"><b>Go Back</b></a> ]");


          }


     }





     foreach ($_POST as $secvalue) {


         if ((eregi("<[^>]*onmouseover*\"?[^>]*>", $secvalue)) ||   (eregi("<[^>]*script*\"?[^>]*>", $secvalue)) ||   (eregi("<[^>]*style*\"?[^>]*>", $secvalue))) {


         die ("<center><img src=images/logo.gif><br><br><b>The html tags you attempted to use are not allowed</b><br><br>[ <a href=\"javascript:history.go(-1)\"><b>Go Back</b></a> ]");


         }


     }


}

I think one loop is quicker than 3 seperate ones, especially since $HTTP_GET_VARS and $_GET are identical to one another.

Thoughts on this? Bye bye for now

-Bill (Audioslaved)

Site Admin/Owner Joined: Aug 27, 2002 Posts: 17088

In theory this looks great and should work. However, I'm having problems implementing it on my site. It flags my site as an error 100% of the time. I'll keep looking. It's probably some custom coding I have somewhere. Thanks!

Posted: Wed Jun 16, 2004 6:50 am

In theory is correct, i haven't attempted implementing this yet either, I will let you know what I get as well. Smile

Posted: Wed Jun 16, 2004 6:55 am

It's the

Code:

eregi("\"", $secvalue

that's causing it. The _REQUEST is checking more than just POST/GET and " are allowed elsewhere.

Posted: Wed Jun 16, 2004 7:01 am

I was checking out 7.3 code before, my 6.5 has the following:

Code:




$block_code5 = $_GET['block_code'];


$newname = $_GET['name'];


if (!$block_code5) {


 foreach ($_GET as $secvalue) {





     if ((eregi("<[^>]*script*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*object*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*iframe*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*applet*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*meta*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*style*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*form*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*img*\"?[^>]*>", $secvalue)) ||


   (eregi("\([^>]*\"?[^)]*\)", $secvalue)) ||


   (eregi("\"", $secvalue))) {


     die ("<center><img src=images/logo.gif><br><br><b>The html tags you attempted to use are not allowed</b><br><br>[ <a href=\"javascript:history.go(-1)\"><b>Go Back</b></a> ]");


     }


 }


}


$block_code6 = $_POST['block_code'];


$newname2 = $_POST['name'];


if (!$block_code6) {


 foreach ($_POST as $secvalue) {


     if (eregi("<[^>]*script*\"?[^>]*>", $secvalue)) {


     die ("<center><img src=images/logo.gif><br><br><b>The html tags you attempted to use are not allowed</b><br><br>[ <a href=\"javascript:history.go(-1)\"><b>Go Back</b></a> ]");


     }


 }


}

Still a waste, could easily be

Code:




     if (! isset($_REQUEST['block_code'])) {


          foreach ($_REQUEST as $secvalue) {


               if ((eregi("<[^>]*script*\"?[^>]*>", $secvalue)) ||


          (eregi("<[^>]*object*\"?[^>]*>", $secvalue)) ||


          (eregi("<[^>]*iframe*\"?[^>]*>", $secvalue)) ||


          (eregi("<[^>]*applet*\"?[^>]*>", $secvalue)) ||


          (eregi("<[^>]*meta*\"?[^>]*>", $secvalue)) ||


          (eregi("<[^>]*style*\"?[^>]*>", $secvalue)) ||


          (eregi("<[^>]*form*\"?[^>]*>", $secvalue)) ||


          (eregi("<[^>]*img*\"?[^>]*>", $secvalue)) ||


          (eregi("\([^>]*\"?[^)]*\)", $secvalue)) ||


          (eregi("\"", $secvalue))) {


               die ("<center><img src=images/logo.gif><br><br><b>The html tags you attempted to use are not allowed</b><br><br>[ <a href=\"javascript:history.go(-1)\"><b>Go Back</b></a> ]");


               }


          }     


     }

I am implementing both of these to see if they both work on my site.

Posted: Wed Jun 16, 2004 7:16 am

I am beginning to think that the creator's of this do not know regular expressions very well as well. These can all be combined into one, they are already setup using the question mark in each eregi as an optional (not needed/hence optional) why don't they roll all of these into one. Lemme give it a whirl. Smile

Posted: Wed Jun 16, 2004 7:20 am

To see what else it is grabbing, do a print_r($_REQUEST); at the top of your script. For those who don't know, this will let us see on a normal page load what exactly is getting passed via most of the Superglobal arrays along the way.

echo "<pre>";
print_r($_REQUEST);
echo "</pre>";

Posted: Wed Jun 16, 2004 7:33 am

Code:




<  asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfobject classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="someplace/swflash.cab" width="200" height="300" id="penguin">

This will not work regardless as all of the stuff before should not do anything.
However

Code:




<    object=classid blah blah blah>

could still possibly work depending on the browser I am guessing, I replaced the [^>]* with \s* which indicates whitespace from 0 instances and up, I feel this is more realistic, unless there are examples to show me otherwise anyway.

I am looking at why exactly the last two are needed.

Code:




   (eregi("\([^>]*\"?[^)]*\)", $secvalue)) ||


   (eregi("\"", $secvalue))) {

Nothing is coming to mind that would warrant producing an error because of a double quote. Any possible suggestions as to why this is needed? Hmmmmm?

Posted: Wed Jun 16, 2004 7:38 am

Audioslaved wrote:

I am beginning to think that the creator's of this do not know regular expressions very well as well. These can all be combined into one, they are already setup using the question mark in each eregi as an optional (not needed/hence optional) why don't they roll all of these into one. Lemme give it a whirl. Smile

Ya think

? Paul and FB claim fame to that menagerie. In fact, Paul just bragged about it recently as being his Laughing

Posted: Wed Jun 16, 2004 2:00 pm

I talk very loose with my mouth and mean no direct slam to Paul or FB (Though FB pisses me off for other reasons) about their regex capabilities. I mean, I am no genius and am quite novice in development/programming myself, but there are a few things that just "make sense", ya know! Wink

Was anyone able to come up with a reason for

Code:




   (eregi("\([^>]*\"?[^)]*\)", $secvalue)) || 


   (eregi("\"", $secvalue))) {

Being in that check, what possible uses does it have, I am still drawing a blank on this one, the top is saying it starts with a ( goes any number of characters which aren't a > followed by a quotation mark (optional) and then any number of characters which are not a ), followed by a ), hmmmm
so basically (blahblah) is being stripped, in html world, what in the world begins and ends with a (),.... also it isn't possible to call functions from a get or post var, is it? I cant say that blah=get_theme() in the address bar and actually have it do something. This doesn't make sense to me. Maybe someone more knowledgable can help out.

The last one says anything with a quotation mark, lets see here, that is far too generic for my liking what else can we come up with.

I think the main thing to do is throw a huge

Code:




if (! is_admin()) {

around this section as well. I say this because admin's should be able to do whatever the hell they want. If I add a great html block, than I am screwed if I attempt to use any sort of JS. This should assume that admins are almighty and know what they are doing. That is, if we are confident that most of the admin hole's have been blocked, I would at least make this an optional capability for it, leave it up to the owners of a site to let admins slide on this or not. Wink

Posted: Wed Jun 16, 2004 2:31 pm

Audioslaved wrote:

I talk very loose with my mouth and mean no direct slam to Paul or FB (Though FB pisses me off for other reasons)

They both have earned any disrespect they get because they are so disrespectful to others and the community.

Posted: Wed Jun 16, 2004 2:59 pm

I don't think the braces can do anything evil without quotes even on mssql but I'm not 100% sure of that. But I do think its worth your investigation. All those string matches make a huge difference in speed (or the lack of it). Then some people will run with those and add sentinel, protector and Fortress along with a few others for good measure out of paranoia. This has got to be detrimental to any performance expectations.

Posted: Wed Jun 16, 2004 4:22 pm

The only time i can see braces possibly doing any harm is maybe a call to a sql function when doing an sql injection. Kind of along the lines of what you were saying above. Functions on an insert/select such as count() last_insert_id(), etc are a few that come to mind, don't know the feasibility of pulling these off via sql injection though.

Another thing about all these union attacks/sql injections etc, is that the variables are not getting secured properly due to the reliance of register globals. For instance, I believe it was the download module exploit, it sent post information via a GET. That shouldn't be happening period. It is not hard in the case of Adding the downloads to redeclare the variables to only be that of the POST, for example:

From Downloads Module, since we are submitting data (i.e adding a download) it should/could be assumed this will never occur via a GET, and always a POST.

Code:




    case "Add":


    $title = trim($_POST['title']);


    $auth_name = trim($_POST['auth_name']);


    $cat = intval(trim($_POST['cat']));


    $description = trim($_POST['description']);


    $email = trim($_POST['email']);


    $filesize = intval(trim($_POST['filesize']));


    $version = trim($_POST['version']);


    $homepage = trim($_POST['homepage']);


    Add($title, $url, $auth_name, $cat, $description, $email, $filesize, $version, $homepage);


    break;

A little extra code, but now when you add something to the Downloads Module, there is only one way it is going to work, through POST methods, you could even go further to ensure that the request is coming from the local server, that way someone can't setup a form to remotely connect to your script and exploit you via POST methods, (much like AddAuthor POST exploit)

Posted: Wed Jun 16, 2004 4:55 pm

Ahem, to see if it is coming from a POST form on a remote computer, you could do a check for the $_SERVER['HTTP_REFERER'] to see if that is set, if it is, that means it came from a place that is not your direct server, doing a post on your server (i.e someone using a form on your server) will not produce an http referer, doing so from outside sources will produce an HTTP_REFERER, other than that, those are the only differences from POST something locally and posting something remotely. I setup a test script on my site that is a simple form and when submitted prints the $_SERVER array and also the $_REQUEST array.

I also made a simple html form who's form action was set to the script on my server, here are the results of the local submit and the remote submit. You will see there is not much difference

Submitting using a form on my server

Code:




$_SERVER Array


Array


(


    [CONTENT_LENGTH] => 63


    [CONTENT_TYPE] => application/x-www-form-urlencoded


    [DOCUMENT_ROOT] => /home/audiosla/public_html/gt


    [HTTP_ACCEPT] => image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/msword, */*


    [HTTP_ACCEPT_ENCODING] => gzip, deflate


    [HTTP_ACCEPT_LANGUAGE] => en-us


    [HTTP_CACHE_CONTROL] => no-cache


    [HTTP_CONNECTION] => Keep-Alive


    [HTTP_HOST] => gt.audioslaved.com


    [HTTP_USER_AGENT] => Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)


    [PATH] => /bin:/usr/bin:/usr/ucb:/usr/bsd:/usr/local/bin


    [REMOTE_ADDR] => 4.7.244.99


    [REMOTE_PORT] => 3412


    [SERVER_ADDR] => 67.18.39.58


    [SERVER_NAME] => gt.audioslaved.com


    [SERVER_PORT] => 80


    [SERVER_SIGNATURE] => Apache/1.3.31 Server at gt.audioslaved.com Port 80





    [SERVER_SOFTWARE] => Apache/1.3.31 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.3.3 FrontPage/5.0.2.2634 mod_ssl/2.8.17 OpenSSL/0.9.7a


    [GATEWAY_INTERFACE] => CGI/1.1


    [SERVER_PROTOCOL] => HTTP/1.1


    [REQUEST_METHOD] => POST


    [QUERY_STRING] => 


    [REQUEST_URI] => /remotesubmit.php


    [SCRIPT_NAME] => /remotesubmit.php


    [PHP_SELF] => /remotesubmit.php


    [argv] => Array


        (


        )





    [argc] => 0


)





$_REQUEST Array


Array


(


    [text] => hello


    [text1] => hello1


    [text2] => hello2


    [text3] => hello3


    [submit] => submit


    [lang] => english


\";}


)

Submitting using a form from my local machine pointing to the file on my server

Code:




$_SERVER Array


Array


(


    [CONTENT_LENGTH] => 63


    [CONTENT_TYPE] => application/x-www-form-urlencoded


    [DOCUMENT_ROOT] => /home/audiosla/public_html/gt


    [HTTP_ACCEPT] => image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/msword, */*


    [HTTP_ACCEPT_ENCODING] => gzip, deflate


    [HTTP_ACCEPT_LANGUAGE] => en-us


    [HTTP_CACHE_CONTROL] => no-cache


    [HTTP_CONNECTION] => Keep-Alive


    [HTTP_HOST] => gt.audioslaved.com


    [HTTP_REFERER] => http://gt.audioslaved.com/remotesubmit.php


    [HTTP_USER_AGENT] => Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)


    [PATH] => /bin:/usr/bin:/usr/ucb:/usr/bsd:/usr/local/bin


    [REMOTE_ADDR] => 4.7.244.99


    [REMOTE_PORT] => 3377


    [SERVER_ADDR] => 67.18.39.58


    [SERVER_NAME] => gt.audioslaved.com


    [SERVER_PORT] => 80


    [SERVER_SIGNATURE] => Apache/1.3.31 Server at gt.audioslaved.com Port 80





    [SERVER_SOFTWARE] => Apache/1.3.31 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.3.3 FrontPage/5.0.2.2634 mod_ssl/2.8.17 OpenSSL/0.9.7a


    [GATEWAY_INTERFACE] => CGI/1.1


    [SERVER_PROTOCOL] => HTTP/1.1


    [REQUEST_METHOD] => POST


    [QUERY_STRING] => 


    [REQUEST_URI] => /remotesubmit.php


    [SCRIPT_NAME] => /remotesubmit.php


    [PHP_SELF] => /remotesubmit.php


    [argv] => Array


        (


        )





    [argc] => 0


)





$_REQUEST Array


Array


(


    [text] => hello


    [text1] => hello2


    [text2] => hello3


    [text3] => hello4


    [submit] => submit


    [lang] => english


\";}


)

I had to take a few pieces of information out, hope you don't mind! Wink

As you will probably see, the only difference is the HTTP_REFERER, we can now use this as a check with the code above

Code:




    case "Add": 


    if (! isset($_SERVER['HTTP_REFERER'])) {


    $title = trim($_POST['title']); 


    $auth_name = trim($_POST['auth_name']); 


    $cat = intval(trim($_POST['cat'])); 


    $description = trim($_POST['description']); 


    $email = trim($_POST['email']); 


    $filesize = intval(trim($_POST['filesize'])); 


    $version = trim($_POST['version']); 


    $homepage = trim($_POST['homepage']); 


    Add($title, $url, $auth_name, $cat, $description, $email, $filesize, $version, $homepage); 


    } else {


    exit;


    }


    break;

Tested it on my script, seems to work successfully at stopping remote POST methods from working properly. Smile

Posted: Thu Jun 17, 2004 5:39 am

It looks as though my little comments about regex capabilities were not liked very much at Nukecops as I have been banned, when I go there from any of the IP addresses associated with my name, I get an almost blank page that has an image which states Riservato (Means "Classified" in English). However if I route myself through an anonymous proxy, I am able to access the site and login. Weird huh?

This really pisses me off as I am not involved in any pissing contest with Paul or anyone else over there. I am in this for nuke, not a particular team, I venture across many sites and popin where I may to converse, help, and develop with fellow nukers. If I felt that Pauls/FB's regex wasn't coded very smartly (which by the way, I didn't even know it was theirs) then so be it, I pointed it out, I don't see the whole stigma with getting banned because I shed light on the situation. The bigger fact is we are all adults, we all screw up, we all have written sloppy code and we shouldn't be mad when someone else calls us on that. We should learn from it and retain it for the next-time around.

I have seen a pile of B.S in my day and if I did in fact get banned for purposes of this thread than I am deeply sorrowed that what I thought was a good person could have been reduced to something so pitiful. When I left the community for a stint around the end of December, things appeared to be much more peaceful, cooperative and coordinated back then. What is going on with this CMS people?

I guess it happened. HitsFan

Regular Joined: May 31, 2004 Posts: 95 Location: NY

There is new owner of NukeCops, Audioslaved. You are just lucky enough for your ISP's DNS to update extremely fast Smile

Check out the whois information on NukeCops.com. You'll notice a completely new name, etc, for the domain. ZX has finally got rid of NukeCops.com. The owner in the whois is Italian, and 'reservado' is reserved in Italian, I am guessing.

So, you were not banned. Its just that the world hasn't updated DNS yet Smile

Posted: Thu Jun 17, 2004 6:28 am

I have a feeling NukeCops sold the site to FB or an affiliate of his.

Posted: Thu Jun 17, 2004 6:44 am

According to babbelfish, english translation of reservado from italian is "classified".

I have 4 different primary IP's I use, one on my work network, one on the commercial connection at work (roadrunner), two at home (Verizon), the site worked fine before I went to work, while attempting to check at work, it gave me that. But when I use any IP that is not affiliated with the 4 I normally would use, I can get in. At this point what you say does make logical sense, but from my angle, someone considering what I said disrespectful towards someone and taking action makes logical sense as well.

BTW, downloaded and Tapped WorkBoard 1.2 for someone at NExtGEn (http://gt.audioslaved.com) this evening, tap came out great, great job on the Mod! Cheers **Holds up mug** Smile

Posted: Sat Jun 19, 2004 11:20 pm

Going back to the regex, I am wondering why we are taking the user away from his/her experience by giving an error when they submit something containing html, I want to run some idea's of replacements for this method.

Instead of kicking back an illegal html characters error: maybe we can?

1.) strip all submitted tags,...make all submitted < their html equiv and the same for >
2.) replace instances of a bad tag (i.e javascript, iframe, etc) with something that says forbidden tag
3.) replace the < and > as html equiv on only those with tags indicated as bad.
4.) Replace the whole tag < through > with nothing, like it never existed.

What else could be done, need everyone's thoughts? How would you want the data to be handled on your respective sites?

Posted: Sun Jun 20, 2004 1:16 am

As the madness continues to build, found another flaw in the regex's, it pertains to I.E's implentation of JS. If you have a tag that has javascript in it, such as

Code:




<a href="javascript:alert(1);" target="_blank" onMouseOver ="alert(1)">Test</a>

The following methods will still execute that Javascript:

Code:




<a href="javascript(1);" target="_blank" onMouseOver ="alert(1)">Test</a>





<a href="(1);" target="_blank" onMouseOver ="alert(1)">Test</a>





<a href="(1)" target="_blank" onMouseOver ="alert(1)">Test</a>





<a href="j          avascript:alert(1);" target="_blank" onMouseOver ="alert(1)">Test</a>





<a href="j          avas      ccccccccript:alert(1);" target="_blank" onMouseOver ="alert(1)">Test</a>

This is also where the regex for the parenthesis was used

Code:




\([^>]*\"?[^)]*\)

It appears from the above that I.E allows to call JS functions with just using parenthesis. So the above regex is actually a good move to locate this, the only bad thing about this is that it will also kick back HTML chars not allowed if you happen to just use parenthesis in a normal context (i.e something like this).

Having just read up on XSS, IBM has a great read to think about:
here is a quick blurb of what they say in this article (http://www-106.ibm.com/developerworks/library/wa-secxss/)

Quote:

The following is a checklist of ways for webmasters and developers to prevent XSS attacks:

Guarantee that the pages in the Web site return user inputs only after validating them for any malicious code.
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.)
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.
Convert all non-alphanumeric characters to HTML character entities before displaying the user input in search engines and forums.
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.)
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.)

I think moving towards a more replacing type of approach may be more beneficial to preventing XSS attacks on nuke.

Characters to replace could include
< > ( ) #