One word: sandbox<br><br>XSS only exists in OUTPUT, while filtering should exist in both INPUT and OUTPUT. In fact, filtering is not the correct word to use as you should ONLY allow EXPECTED input via GET and require a POST for user controlled input. Upon first review it would be thought that you could create JS to just
form.submit() but as only expected input is allowed via the GET then that will not be an issue.<br><br>Unless you find a way to escape the sandbox, the end user has the destination site in their local zones, they are using an extension that evaluates pages in chrome://, or just a buggy extension, then there will be no interactive javascript ``shell''.
<br><br>One could construct the XSS/CSS to grab an AJAX type of framework from a remote site, but then that site would need to be trusted by the client. Your best bet would be to construct the JS to initialize an JRE Applet and somehow(probably not too hard) get the end user to accept the foreign applet, which would also need to escape the JRE Sandbox Security Model(has been done in the past).
<br><br>Ohh, fun times.<br><br><div class="gmail_quote">On Nov 14, 2007 1:57 AM, XSS Worm XSS Security Information Portal <<a href="mailto:cross-site-scripting-security@xssworm.com">cross-site-scripting-security@xssworm.com
</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Thank you for these points Dave, I am replying:<br><br>With the XSS we can say it is shellcode because shellcode is the code injected into process or programme that contain bad validation of input - we say shellcode because it contains system call to execute shell commands - i think so?
<br><br>XSS vulnerability is bad validation of input also (and output as you said in bold)<br><br>and with injected code and web 2.0 and fat rich clients (like in the USA) we can make java scripts with reverse shell to desktop with XSS
<br>& get interactive control over fat clients and make them do things and we can write interpreter and make it 'shell' if you want it easy (-;<br><br>So XSS is input validation bug just like buffer overflow and we inject code that will be interactive 'shell' and execute action or command on behalf of user so XSS injection code = shellcode. Only differences in what you consider 'shell', 'command', 'action', 'user', no?
<br><br>With the code is posted we cannot see any bugs either but as you say maybe fundamentals<br><br>output $_GET['variable']<br><br>is this a vulnerability? I am not programmer but I have heard said that input validation is sometimes maybe the cause of vulnerabilities.
<br><br>Thanks vaj.<div><div></div><div class="Wj3C7c"><br><br><br><br><div class="gmail_quote">On Nov 14, 2007 5:51 PM, dave-san <<a href="mailto:dave@subverted.org" target="_blank">dave@subverted.org</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Comments inline..<br><div><br>XSS Worm XSS Security Information Portal wrote:<br></div>> *0day XSS Exploit for Wordpress 2.3* – wp-slimstat 0.92 – [<a href="http://xssworm.com" target="_blank">xssworm.com
</a>]<br><div>><br>> Source:<br>> <a href="http://xssworm.blogvis.com/13/xssworm/0day-inject-exploit-for-wordpress-23-xsswormcom-all-version-vulnerable-with-no-patch/" target="_blank">http://xssworm.blogvis.com/13/xssworm/0day-inject-exploit-for-wordpress-23-xsswormcom-all-version-vulnerable-with-no-patch/
</a><br>><br>> There is a serious holes in wordpress 2.3 that can be used with XSS by a<br>> blackhat hacker to attack the wordpress administrator and steal cookies from<br>> blogmins. This attack is known as 0day because it has just been reported to
<br>> public and this is first day of public vulnerability, and *0day means<br>> 'published.*'<br>> Proof of concept:<br>><br>> <a href="http://wordpress-web-blog.com/wp-admin/index.php?page=wp-slimstat/wp-slimstat.php?panel=1&fi=/feed/&ff=1&ft=" target="_blank">
http://wordpress-web-blog.com/wp-admin/index.php?page=wp-slimstat/wp-slimstat.php?panel=1&fi=/feed/&ff=1&ft=</a><xss<br>> shellcode><br>><br><br></div>Hmm.. XSS shellcode? That's a new one for me. I'll take this to mean the
<br>injected script. From your post, I don't think you mean "shellcode" in<br>the traditional sense.<br><div><br>> This attack to be used against wordpress web blog blogmin to steal<br>> blogosphere token to hack blogs. Of course we have included exploit code for
<br>> this bug at the below.<br>><br>> We have looked at coding for wp-slimstat but we cannot see any problem with<br>> input validating. Maybe some of the <a href="http://xssworm.com" target="_blank">xssworm.com
</a> readers can show us where<br>> problem is in the php code because we cannot see any porblem here:<br>><br>> –snips:<br>><br>> C:\temp>findstr GET wp-slimstat.php<br>> $myFilterField = intval( $_GET['ff'] );
<br>> $myFilterType = intval( $_GET['ft'] );<br>> $myFilterString = $_GET['fi'];<br>> $myFilterInterval = $_GET['fd'];<br>> $myFilterField = intval( $_GET['ff'] );<br>> $myFilterType = intval( $_GET['ft'] );
<br>> $myFilterString = $_GET['fi'];<br>> $myFilterInterval = $_GET['fd'];<br>> '.(!empty($myFilterString)?'— <a<br>> href="?page='.$_GET['page'].'&panel='.$_GET["panel"].'">'.__('Reset
<br>> filters', 'wp-slimstat').'</a>':").'<br>> <input type="hidden" name="page" value="'.$_GET['page'].'" /><br>> <input type="hidden" name="panel" value="'.$_GET["panel"].'" />
<br>> <input type="hidden" name="fd" value="'.$_GET["fd"].'" /></form>';<br>><br><br></div>It's late, and I might have missed something, but from the above, I
<br>don't see where the vulnerable parameter is being written back to the<br>HTML response. Therefore, I don't think there is enough code in the<br>lines above to locate the entire issue (though it looks like other
<br>parameters are vulnerable too). You mentioned:<br><br> ft=<xss shellcode><br><br>So, in this example, "ft" is the vulnerable parameter. Trace what<br>happens in code with that parameter after it receives input. I'd guess
<br>that there is something like..<br><br> echo '<maybe some HTML crap here>'. $myFilterType .' more...<br><br>or<br><br> echo '<ditto>'.$_GET["ft"].'<ditto>..<br><br>
Perhaps take a look at where they missed the output formatting/encoding<br>for HTML. I may be so bold as to suggest that the lack of output<br>encoding is the major reason that XSS exists.<br><div><br>> –snips
<br>><br>> With programmor using $_GET variable from user into echo into html output<br>> maybe php automatic GET validation filtering is not working for security? We<br>> are not programmers of php so we cannot see any porblems here as bug are too
<br>> complex to understand.<br></div><div>> Many thanks for your comments on this vulnerability in wordpress 2.4<br><br></div>..edit<br><br>><br>> Thanks vaj<br><div><div></div><div>
><br><br>_______________________________________________<br>Full-Disclosure - We believe in it.<br>Charter: <a href="http://lists.grok.org.uk/full-disclosure-charter.html" target="_blank">http://lists.grok.org.uk/full-disclosure-charter.html
</a><br>Hosted and sponsored by Secunia - <a href="http://secunia.com/" target="_blank">http://secunia.com/</a><br></div></div></blockquote></div><br><br clear="all"><br></div></div><div><div></div><div class="Wj3C7c">--
<br>Francesco Vaj [CISSP - GIAC]<br>CSS Security Researcher
<br>mailto:<a href="mailto:vaj@nospam.xssworm.com" target="_blank">vaj@nospam.xssworm.com</a><br>aim: XSS Cross Site <br>------<br>XSS Cross Site Scripting Attacks<br>Web 2.0 Application Security Information Blog (tm) 2007
<br><a href="http://www.XSSworm.com/" target="_blank">
http://www.XSSworm.com/</a><br>------<br>"Vaj, bella vaj."
</div></div><br>_______________________________________________<br>Full-Disclosure - We believe in it.<br>Charter: <a href="http://lists.grok.org.uk/full-disclosure-charter.html" target="_blank">http://lists.grok.org.uk/full-disclosure-charter.html
</a><br>Hosted and sponsored by Secunia - <a href="http://secunia.com/" target="_blank">http://secunia.com/</a><br></blockquote></div><br>