PDA

View Full Version : XSS exploits, whitelists, vbulletin security?


jdh
April 13th, 2007, 03:26 PM
I assume, based on the following quotes about XSS from Wikipedia, that the ability to post messages in this forum in HTML means that malicious users could post messages containing javascript that exploits XSS vulnerabilities?

If this assumption is true, then merely opening a thread containing a malicious message could do bad things. If this is true, then any TAPCIS member could be at risk of XSS attack if tapcis.com were whitelisted (IE trusted zone, or FF NoScript whitelist). Whether the new anti-XSS features of FF NoScript would shield from this 100%, I don't know.

Furthermore, even if the TAPCIS vbulletin editors block that from happening, a malicious user (or even an innocent user) could include a URL containing malicious javascript. Here one would still be safe provided MS IE Internet Zone security is set HIGH or NoScript is not set to globally enable JS.

I believe last year I posted a msg somewhere here linking to a MS article recommending all network administrators to implement policies forcing "Internet Zone" security in MS IE to HIGH. (Which I think also assumes that management pre-approved sites would be somehow globally whitelisted within the particular company LAN.)

I think the bottom line is that if one goes to any web site that allows users/members to post info in HTML, then the risk to oneself is considerably raised if scripting is enabled and the site is whitelisted.

" Type 2 This type of XSS vulnerability is also referred to as a stored or persistent or second-order vulnerability, and it allows the most powerful kinds of attacks. A type 2 XSS vulnerability exists when data provided to a web application by a user is first stored persistently on the server (in a database, filesystem, or other location), and later displayed to users in a web page without being encoded using HTML entities. A classic example of this is with online message boards, where users are allowed to post HTML formatted messages for other users to read. "

http://en.wikipedia.org/wiki/Cross_site_scripting

" Many browsers can also be configured to disable client-side scripts on a per-domain basis. This is a common mistake, whose failure is that it blocks bad sites only after the user knows that they are bad, which normally of course is too late. Therefore only a functionality that by default blocks all scripting and external inclusions, and then allows the user to enable it on a per-host-basis is the only way to greatly enhance the convenience of such a system. Doing this has been possible for a long time in Internet Explorer (since version 4) setting up the so called "Security Zones", and in Opera since version 9 using its "Site Specific Preferences", slightly more discoverable and usable. A user friendly solution for Firefox and other Gecko based browsers is provided by the open source NoScript extension, featuring also a specific Anti-XSS protection functionality. "

" One of the major drawbacks to this mitigation is that most users are ignorant of such measures, and would not know how to properly secure their browsers for such applications, if these security settings were disabled by default. The other major drawback is that many insecure sites simply don't work without client-scripts, thereby forcing the user to disable the protection for that site and opening their system to the threat. "

http://en.wikipedia.org/wiki/Cross_site_scripting

One of the main purposes of these XSS exploits is to steal authentication cookies, i.e. the bad guys get access to your bank, credit card, etc. They could also use your ID to harass you, e.g. post messages related to child porn or terrorism to bring FBI down on you.

And keeping your virus definitions and MS critical patches, etc. up to date will probably not help, since the security holes are on the web sites, not on your PC. To put it another way, browser + HTML + Javascript = permanent infinite security hole, BY DEFINITION.

Oh happy day,

DH

Judy G. Russell
April 13th, 2007, 09:24 PM
I assume, based on the following quotes about XSS from Wikipedia, that the ability to post messages in this forum in HTML means that malicious users could post messages containing javascript that exploits XSS vulnerabilities? Every version of vBulletin since 2.2.1 has not been vulnerable to the cross-scripting issue. (We are now running on 3.6.5.)

sidney
April 13th, 2007, 10:57 PM
Every version of vBulletin since 2.2.1 has not been vulnerable to the cross-scripting issue

I would modify that a little bit. XSS is like buffer overflow - It is a category of exploit that can be the result of sloppy programming or just a mistake. You can never say for sure that the last one has been found. However, the potential for XSS vulnerabilities has been well known for quite a while and any popular program such as VBulletin has been subject to much scrutiny and correction of problems that were found. I don't see any reports of verified XSS vulnerabilities in VBulletin since version 3.0 was released.

Just like the techniques for XSS are well known, so are the techniques for programming web sites to avoid introducing XSS vulnerabilities. It is up to the programmers to follow proper guidelines to reduce the likelihood of vulnerabilities, and to fix XSS problems as soon as they become known.

Judy G. Russell
April 14th, 2007, 10:35 AM
I would modify that a little bit. ... I don't see any reports of verified XSS vulnerabilities in VBulletin since version 3.0 was released.I didn't mean to suggest anything was invulnerable, but rather than the last reported vulnerability was back with a 2.x version.

sidney
April 14th, 2007, 04:08 PM
but rather than the last reported vulnerability was back with a 2.x version.

I'm not trying to be overly pedantic, but I mention this because they serve to highlight that vBulletin is pretty secure. There actually have been two reports since 3.0 came out.

One of them said that as an administrator you can if you want, using the control panel, introduce malicious XSS script code into HTML that will be displayed to users. That report was dismissed by the vBulletin as being as designed. Admins are allowed to do what they want with the site, since they can do whatever they want independently of the code in vBulletin. XSS vulnerabilities generally refer to the ability of an attacker to get malicious script code into the browsers of users, and it is reasonable to assume that the site admin already has that ability.

The other report was for the latest version of vBulletin, was provisionally reported by the security group that it had been sent to, and then withdrawn by them when further investigation showed that no version of vBulletin was susceptible to the exploit.

Judy G. Russell
April 14th, 2007, 07:51 PM
I'm not trying to be overly pedantic, but I mention this because they serve to highlight that vBulletin is pretty secure. There actually have been two reports since 3.0 came out.

One of them said that as an administrator you can if you want, using the control panel, introduce malicious XSS script code into HTML that will be displayed to users. That report was dismissed by the vBulletin as being as designed. Admins are allowed to do what they want with the site, since they can do whatever they want independently of the code in vBulletin. XSS vulnerabilities generally refer to the ability of an attacker to get malicious script code into the browsers of users, and it is reasonable to assume that the site admin already has that ability.

The other report was for the latest version of vBulletin, was provisionally reported by the security group that it had been sent to, and then withdrawn by them when further investigation showed that no version of vBulletin was susceptible to the exploit.Thaks for that further explanation, Sidney. I appreciate knowing the full story, and am glad that this software is (at least reasonably, given things the way they are) a good choice for us.