Before to many people starts writing that there is a security problem, I would like to give my statement . In the current version of NextGEN Gallery it’s possible to include javascript commands inside the description field (So called XSS vulnerability) as long as the user has admin access to the blog . It was my intention to allow here HTML code and I see no security flaw unless somebody has access to your blog… but then he can enter also a javascript code inside a blog post or a page or do other bad things.
So is this now a problem or not ? It’s a simple thing to strip out any HTML code, but does somebody see a real security problem ? Should I disallow any HTML code for editors , auhors and admins ?
alex.rabe 
As long as users can’t inject code into comments or submit nextgen galleries with malicious code there is no problem. If a bad guy gains
admin rights to blog there are more ineresting places to inject code for him.
I think its right. In my description field there are many HTML Tags. Links to posts on the blog eg.
But to include JS in the field you must have admin acces. I think it is not a security issue
Definatly not! Its a security issue to allow idiots to have admin acces to ones blog. But maybe there’s a way to filter js in the description via regexp orso if it still bothers.
best regards
bee
I see no issue with this at all and no you should not remove html code in the description field. If a person has admin rights to the blog, they could include javascript and more into in the pages as well.
I don’t view this as a security issue. As expressed before me, “Its a security issue to allow idiots to have admin access to ones blog.”
I just want to know how to get the plugin to work! I created a gallery with 7 photos. I then created a new page. I’ve put the [gallery=ID] in the tags, and it didn’t work. I put it straight into the html code, and it doesn’t work. What else can I do? I don’t know where else to look for some help with this.
Not a security issue.
Nope, I’d say it has more pros than cons. If someone has admin powers in a blog then they can do much worse things than this…
Hello, i have alert you (pense libre) because i use happyless your plugin and when i see that in the french forum i was chocked i have think the best is to inform you first…. why they don’t do that, not honnest for me.
i have never desactiv your plugin
i have write a complement just now in quote of this post, with your link
and talk : 200 000 blogs !
Apparently the people above have NO idea what XSS means.
* disclaimer: it’s been a long while since I did a lot with wordpress code wise, so I _might_ be wrong about some of the statements below. *
Let’s explain this with an example. Let’s say Alex is logged in on his own website to check the comments waiting to be moderated. One of them has been made by H. Acker wich nicely states a solution for a problem Alex mentioned on his blog at the EvilWebsite. So Alex checks that page only to see some nonsense talk about birds and bees. No problem there you might say.
But if that H. Acker added some malicious javascript to that page, the person executing *that* code IS Alex, who happens to have full admin rights on his own blog. Now if that code is requesting the AddNewGallery function on Alex’s his blog, that new gallery *will* be created by Alex without his knowledge. And that’s what XSS means.
Now, from what I remember, WordPress does have some form of anti XSS functionality available, so if you’re not using that I suggest you start using it. And *always* validate incoming data, even when it’s supposed to only be coming from a “trusted source”. (remember: there is no trusted source on the internet)
And to give you an awnser to your question:
– Is it a problem: yes!
– Should you allow HTML: sure, as long as it’s checked against a whitelist of allowed elements and attributes
– Should you allow javascript: never!
Regards,
Sjon,
Thanks for enlightening everyone on the XSS problem, this is VERY useful information.
So, malicious javascript could cause damage if it is injected into a publicly available comment form field and it gets executed by a user with admin access within the WordPress admin-interface.
In Alex’s case, the NextGEN description form field is nested/accessed privately, within the WordPress Admin.
For someone to inject malicious javascript into this description form field, they would need to gain admin-level access to the WordPress admin-interface to inject the code.
Therefor, the natural admin-access-required infrastructure of NextGEN is designed to avoid XSS attacks from a public entry point.
—
The management responsibility of NextGEN is such placed onto the initial administrator that grants admin-level access to the users of the WordPress installation.
Sjon, Mike,
thanks for your comments.
I reviewed many times my code for XSS,RFI,SQL Injection and more. I’m sure that I didn’t find all things, but I’m doing my best. In this case the reporter said that it’s possible to include javascript in description field. That’s correct if he has access to the blog/manage gallery page.
Sjon, in your case H.Acker must place on his page a hidden POST submit to the manage gallery page. So that Alex (the admin) without is knowledge add the evil script code. But this is not possible unless H.Acker have the correct WordPress Nonce (http://markjaquith.wordpress.com/2006/06/02/wordpress-203-nonces/), which I implement on each admin page.
If this is not enough security at all, let me ask why nobody claim that JavaScript code can be implemented on each page/post ?
Sjon, you are mixing up XSS and CSRF.
http://en.wikipedia.org/wiki/CSRF
Alex, if you’re using all available anti-hackery wordpress provides, you’ve probably done most you can… My comment was more ment to “enlighten” people on what is a vulnerability and what not…
Daniel, like I said, it’s been a long while… 😉 I’ve put brushing up on xss/csrf/et al on my todo list…