tag:blogger.com,1999:blog-732257695511948254.post4402203552008598830..comments2022-11-09T05:58:31.969-08:00Comments on Nibble Security: XSS flaws are boring!Claudio Criscionehttp://www.blogger.com/profile/12202628660778574382noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-732257695511948254.post-13180782271547950902015-09-12T03:56:32.759-07:002015-09-12T03:56:32.759-07:00This comment has been removed by a blog administrator.سما احمدhttps://www.blogger.com/profile/15427149796352259395noreply@blogger.comtag:blogger.com,1999:blog-732257695511948254.post-90657851245535573232015-09-12T03:56:25.445-07:002015-09-12T03:56:25.445-07:00This comment has been removed by a blog administrator.سما احمدhttps://www.blogger.com/profile/15427149796352259395noreply@blogger.comtag:blogger.com,1999:blog-732257695511948254.post-33061957755244526262009-07-28T05:27:43.436-07:002009-07-28T05:27:43.436-07:00XSS flaws, per se, are boring. The exploitation of...XSS flaws, per se, are boring. The exploitation of such flaws is interesting and challenging indeed.<br /><br />Even if I tend to agree that there's no way (as of today) to exploit such finding, I disagree with a few other things.<br /><br />Actually, using proprietary ActiveX Objects (e.g. Msxml2.XMLHTTP.3.0), we can easily specify an arbitrary HTTP request method (including our payload) as well as we can read data back. Due to the same origin policy for XMLHttpRequest, we still require a cross-domain flaw in order to exploit the finding. Fortunately, browser bugs may help us. <br /><br />Even if the XSS requires the same pre-conditions as for exploiting the TRACE method, I don't fully agree with the parallel. The TRACE method is a server-side configuration that can be easily disable. It is considered an insecure HTTP method thus best practices suggest disabling it. This is rather a bug. It may be not so easy to fix it and a patch is likely required (e.g. the default response page is hardcoded). <br /><br />Besides the specific OC4J issue, it is worth to mention that it is important to disclose such kind of flaws (XSS, XST, ...). It's time consuming or maybe lame but it makes sense for a couple of reasons. First of all because we need complete knowledge bases in our automatic tools (e.g. Nikto), which makes our job less painful. This is especially true if you have to audit several systems a day. Moreover, the web technologies are changing all the time and we cannot ensure the non-exploitability of some issues. As you know very well, it is just a matter of time before the next weak technology will appear.<br /><br />See ya in the next sec conference. Cheers!Luca Carettonihttps://www.blogger.com/profile/09957564681262364569noreply@blogger.comtag:blogger.com,1999:blog-732257695511948254.post-44385478168131730042009-07-23T01:54:34.544-07:002009-07-23T01:54:34.544-07:00Actually, I would have said it the other way aroun...Actually, I would have said it the other way around, damage caused aside, straight xss flaws are just as boring as your typical stack based buffer overflow, but xss flaws can and do get more interesting if you simply pretend those bugs don't exist and try to look for other problems :p<br /><br />What most people can't agree on is what the impact is, how useful they are at being used against specific targets, especially those that aren't social networks, etc.<br /><br />In any case, I don't see how the OC4J issue is an xss issue, from what I know of browsers, there is no way to force such a request to be sent and the response then _rendered_ by a browser. Hence there is no xss.<br /><br />To draw some parallels before you get the chance (:p), I realise that in some cases we assume that an exploit couldn't be crafted, even if we cannot, and we cry foul when exploitable bugs are classed as DoS, this is based on previous experience with the intricate and maleable nature of memory corruption exploits (and many people's failure to grasp that when std. techniques do not work it doesn't mean it's not exploitable), and a wide array of examples where supposedly non-exploitable bugs were exploited.<br /><br />However, to exploit the OC4J 'bug', we would need a way to specify an arbitrary method name cross-domain and have the result rendered. Now, given that this functionality does not exist in any well known places (browser js, flash, java), we can probably assume it's hidden away somewhere unaudited. In which case, we can probably agree that it will allow TRACK/TRACE requests, in which case, you just throw your payload into the URL component and it will come back unfiltered, viola.<br /><br />Does that mean TRACK/TRACE is a bug? Ok this is subjective, but I think: No it means browsers/whatever shouldn't be letting people make such requests.<br /><br />Also, since I'm not a sysadmin, just a hacker, if you can't make an exploit out of it, it's useless.<br /><br />Now that I've gotten off my soapbox, I hope you can pull out some tricks to make an exploit out of your bugs and prove me wrong :pkuza55https://www.blogger.com/profile/03932544559060480887noreply@blogger.com