Page 1 of 1

SQL Injection Attack

Posted: Fri Dec 30, 2011 6:10 am
by szsori
Most of you know that we have a lot of security holes in the current site and that's the main reason we're rewriting the new site. We were featured in an article today on Tweakers.net because someone used one of the SQL injection holes to get the user list and then do a lookup of the passwords using MD5 tables. I spent a little time today closing some of the security holes, but doubtless some others remain. The current code is just horrendous to deal with, so it's hard to track them all down without putting a lot of time into it. Time which I currently don't have.

We strongly suggest that you do a couple things, since we don't know how many times this has been done already nor if holes exist that can be exploited now:
  1. If you use the same email/password combination on TheTVDB that you use on other sites, we recommend changing it on those sites.
  2. We recommend that you use a password on this site that you don't use elsewhere.
  3. We recommend that you change your password on TheTVDB.

As a general practice you should do these things even without security issues at websites that you visit. I recommend the use of LastPass.com or a similar password management tool to help maintain multiple passwords. Finally, if anyone would feel more comfortable having your account removed entirely from the site, please send me a PM with your email and username and I'll get to it ASAP.

Note that this does not affect the forums, but if you use the same username and password in the two systems, you should probably change your forum password. I'm quite sorry about this.

Re: SQL Injection Attack

Posted: Fri Dec 30, 2011 11:17 am
by barttech
Bit shocked by this news, but not especially by the vulnerability. A lot of sites have this as a result of many lazy or unexperienced programmers. More shocked by the fact someone would bother to harm this great project. Hope you get to fix it soon. Good luck!

Maybe this can be a bit of help for the time being ;)

First line in index.php:
<?php foreach ($_POST as $key=>$val) $_POST[$key] = str_replace("'", "\'", $val); ?>

Re: SQL Injection Attack

Posted: Fri Dec 30, 2011 12:48 pm
by dunpealhunter
The person who did this did not do it to harm thetvdb, at least not according to the article at tweakers.net. He informed thetvdb over a week ago about the security hole and only when no action was taken he published his results to tweakers.net.

Re: SQL Injection Attack

Posted: Fri Dec 30, 2011 1:00 pm
by Coco
The current site has tons of security holes,and we don't have time to fix them all. We decided to fix them by making an entirely new site with proper security rather than waste time we don't have on the current site. If people keep attacking the current site the only thing they might manage to do is get us to shut it down completely until we can finish the new one.

Re: SQL Injection Attack

Posted: Sat Dec 31, 2011 7:33 am
by dwjp90
Please, we ask that If anyone notices unauthorized changes to any shows to quickly report them on the forums.

Re: SQL Injection Attack

Posted: Mon Feb 13, 2012 5:28 am
by kross
I was using thetvdb with XBMC some time ago and just came across recently and noticed the SQL flaws too. Seems you lowered the risk a little bit by some kind of basic intrusion detection, hehe.

Of course an IDS shouldn't be the main security concept, but as you have stated the current code is hard to maintain, so you may want to have a look at https://phpids.org. It is an intrusion detection system written in PHP and detects A LOT of SQL and XSS attacks. Unfortunately the website is offline currently, I hope they will come back and the project is still alive. I took a detailed look at PHPIDS two or three years ago and it did a good job so far.

But now why i'm initially signed up: If you're writing the site new from scratch, did you thought about developing it publicly as a open source project on Github? Some advantages:
  • Other programmers may contribute code
  • Other programmers may inform you about security issues in your code
  • Other programmers may discuss about the code architecture
  • Users can file bugs
  • Programmers less likely will use "dirty tricks" in programming when it is publicly visible ;)
  • A current version is available as open source, not like the 4 years old code at sourceforge :) IMO it makes a project more reliable because you know the code is still there, even if the site might be shut down some day.

I'm involved in several open source projects at Github and i can tell that after you got some knowledge with git it's really a charm how easy it is to work together.

Re: SQL Injection Attack

Posted: Mon Feb 13, 2012 12:41 pm
by szsori
We did provide it on Sourceforge and received offers from people to address the security concerns on the site, but none followed through. Open sourcing projects is great as long as there's interest in providing assistance. When assistance doesn't come through, however, then you're just publishing your security holes publicly.

As for the age of the code on Sourceforge, I decided that we wouldn't be going that route any more for two reasons: 1) we weren't getting community support with the code and 2) other sites started looking at the code in order to make their own projects, which is a bad idea given the overall state of that code.

Re: SQL Injection Attack

Posted: Mon Feb 13, 2012 7:41 pm
by kross
I completely understand your concerns and i agree that it wouldn't make much sense to publish an current version of the old code. When i talked about open-sourcing at Github i was referring to a future, rewritten code as mentioned by Coco.

When it comes to a new version i don't see any drawbacks of publishing the code at an early stage of development. Okay, still no guarantee that some people will contribute to the project, but if the development is happening at some popular platform like github, it will be much more likely because it's easier to push code to the project. I could imagine that at least some devs who are using the API will take a look at your code.