Preventing XSS attacks with GT

registered · Posted: Sun Jun 20, 2004 2:35 pm

Doing more research folks, the following is great if you are using a GT version like NExtGEn (fully tapped modules) and are sure that you only want people to access your .html type links.

The .html type links for the most are setup by default to be cleansed because the rules in the .htaccess are setup to only allow certain characters, so trying to stuff in an xss attack does not normally (I say normally because there could possibly be a few holes) work with the .html URL's.

Taking that logic, why not just prevent the way the URL's are called normally from occuring. So instead of a modules.php?name=blah request, we only now want the .html requests. So say we have the Web_Links module, clicking on links.html gives a $_SERVER['REQUEST_URI'] of

Code:




[REQUEST_URI] => /links.html

And likewise for inputting modules.php?name=Web_Links

Code:




[REQUEST_URI] => /modules.php?name=Web_Links

Now for extra protection, any URI's coming from the untapped part of the module (which we don't want people to access directly) will be redirected to the default links.html section of the site, try running xss on that! Smile

Code:




//I only want people to use my NExtGEn side


$theurl = $_SERVER['REQUEST_URI'];





if (eregi("(.*)name=Web_Links(.*)", $theurl)) {


//You are a php link, Goodbye!


Header("Location: links.html");


}

That can easily get around your script having two doors, I know me using NExtGEn I am comfortable with the html side and no longer really want people exploring via my php side. Just some food for thought, any thoughts, etc.

Of course, this is a work in progress, feel free to contribute. Smile

Take it easy y'all,

Bill (Audioslaved)

Posted: Sun Jun 20, 2004 3:02 pm

FYI,
The above will not affect users submitting web_links throught their .html frontend, it also does not affect the admin backend.

This effectively stops xss on the Web_Links module from what I can tell. Especially when using my modded Web_Links module which does not pass anything related to the title of the link in the URL. By default, the title/ttitle is passed in the URL, this can make for some sticky situations, especially since there are no checks done on said ttitle to ensure that ttitle is actually ttitle. That same can apply to the Downloads Module. Take this site for instance.

To view the details of Ravens Nuke 7.1 Patched Final, the following URL is produced

Code:




http://ravenphpscripts.com/downloadview-details-87-PHP-Nuke_7.1_FINAL_-_Patched.html

I can rename the URL to something else and it will still work properly

Code:




http://ravenphpscripts.com/downloadview-details-87-Why_Does_Raven_Allow_this_to_be_Passed.html

Though it does no immediate danger, it may be we are allowing a user to much flexibility with their requests. If the variable is not checked and is relying strictly on user input(s), why is it their in the first place? Just 2 cents.

On with the research! Till we meet again

-Bill (Audioslaved)

Posted: Sun Jun 20, 2004 6:13 pm

Holy Crap, this article puts XSS into some serious perspective, give this a read if you are concerned with Nuke's security. Shocked

[ Only registered users can see links on this board! Get registered or login! ]

Research continues, progress is being made.

Till we meet again Smile

-Bill (Audioslaved)

Regular Joined: Aug 23, 2003 Posts: 77

if you could do this don't allow spaces after html, that would fixed XSS problem