A vulnerability in the website of the UK Parliament appears to be exposing confidential information, including unencrypted login credentials, a Romanian hacker wrote on his blog. The SQL injection vulnerability is on this page, the hacker, who goes by the moniker Unu, told The Register. By tacking database commands onto the end …
Why have a passwd?
I don't have a lot of sysadmin experience - but if you are running a site likely to be such a target why allow network logins to the box at all?
Surely for the occasional need to change the logo of the current set of crooks you can send someone to the console?
I say we ...
extradite this Unu fellow. Then bring back hanging. That's the only way to deal with these "hacker" types.
I see Moss is one of the users.
Surely HE wouldn't make such a mistake!
If your site is vulnerable to SQL injection you deserve everything you get.
It's neither difficult nor expensive to scrub input data.
Has little Bobby Tables visited the site yet?
And how long before he does? This is the kind of thing The Daily WTF would be all over in a heartbeat.
who set up the web site. Two obvious possibilities suggest themselves:
a) the teenage child of an MP in need of a summer holiday job; or
b) EDS (or one of the other usual suspects).
In either case a severe beating with a clue-stick would appear to be in order.
The really depressing thing is that I can no longer tell the difference between the handiwork of a clueless teenager and a major IT corp.
Am I stating the obvious?
Has anyone else found that, despite the blurring, the password for 'fulera' is stupidly easy to see, especially with the Reg's helpful superhero hint?
It just jumped right out, soon as I looked at it!
Big fat FAIL to the Government, once again. Silly fuckers.
They have not got a clue have they?
That really is shocking that a site as high-profile as a government site is vulnerable to SQL injection. It's the most basic type of attack that can be directed at web applications and the first thing I always make sure I've got licked. Proper input validation is essential.
Sums UK.gov up really!!
Anyone for a national database?
My local theater uses good passwords
I was in there last year buying tickets for a show.
One old dear was entering booking information into the system and in front of everyone asked the person next to her what the password was.
"It's P-a-s-s-w-o-r-d" replied the other one.
"Has little Bobby Tables visited the site yet?"
No but I think someone should copy the existing tables and then drop them all.
That will shake someone enough to make them close this security hole...
For those who don't get the reference...
...you should be ashamed of yourselves.
Every time, I'm still amazed at how many "senior" developers are absoloute retards with no understanding of proper design or security.
Mosaic doesn't work well with thumbnails
Brains work in strange ways. Looking at the mosaiced image in full res doesn't produce any hints as to what the passwords might be. But looking at the thumbnail as shown in the article, one can easily tell the arachnid superhero's name, and it's also very easy to guess which of the other accounts have the same password as the account name. Of course, it's too late to do anything about this now -- I'm certainly not the first to notice that...
Good job GCHQ
In the last two months, XSS vulnerabilities in MI5 and the MOD. Last week I prove it was possible to turn the NHS website into a Weapon of Mass Destruction using XSS, now parliament is exposing herself due to SQLi.
According to http://www.gchq-careers.co.uk/default.aspx?id=3
"Our role is also to protect the Government’s communication and information systems from hackers, interference and disruption."
What do you expect?
Half of the government is still mandating IE6!!!!!!!
...showing php errors on the page. N00bs.
It's great to see that they're abstracting the data adapters, rather than using native function calls for everything. I mean, only spaghetti-coders use the native function calls in the raw...Oh, wait.
Failing that, maybe the Great School of "Use Native Functions For Everything" should teach its followers about mysql_add_slashes, before they teach mysql_fetch_array?
The source of all your problems
If you can't make a secure website, probably best not to leave the company name, "Reading Room", in a file:
...assuming that they were also responsible for the development of the site.
Nothing to Hide - Nothing To Fear
Its so obvious.
We are so confident that we have nothing to hide that we leave our websites open for all to inspect....
These are honey pot servers. They are designed so that Hackers can breach security on these minor sites and leave the more important sites along.
Ohhhhhh. Look over these TERRORIST!!!!! ... What webpage? Where? Don't know what you are talking about. Is that your camera sir?
Choose you own excuse and issue to increasing less gullible public
icon: Shouty: Do something different Vote for a change
As of 10:44 02/09/08
They're "working on and [sic] fix"
Allowing this sort of database access from a website is a COMPLETE no-no. Ignore whether the passwords were encrypted or not, that's not an issue.
But a website that allows modification of SQL queries in the URL string... you might as well just turn the machine off for the good it'll do.
Seriously, what's hard about submitting the page query data to the server (NOT as an SQL query, but as form entries), having the server scripting language sanitise that information down to the invididual elements on the submitted form and building its *own* SQL query from pre-defined stanzas that it concatenates based on the form data. If you have a brain, you even make correlate the form data against the login/form accessed to ensure it has access BEFORE you build the SQL query. In this way, it's impossible for someone to turn SELECT ALL FROM... into DROP TABLE or anything else equally as dangerous, such as accessing private fields with passwords in them. The worst that'll happen is they might find some concatenation of the pre-defined stanzas that reveals a *little* more information than you wanted them to.
This is like having a DOS command prompt in every page of your website, and the commands typed in are tacked onto the URL and executed as-is by the server-side. It's *that* dangerous and, yes, *that* stupid.
http://www.theregister.co.uk/?deltree_C:\*.* <-- would you allow that to even be POSSIBLE, let alone likely to actually execute (even if running on a read-only filesystem)? No. So don't embed ANY form of direct SQL in GET/POST queries.
As of 11:49 02/09/09
At least they've fixed the "and" typo! (Maybe someone there reads El Reg?!)
"This site is currently unavailable, we are working on a fix and should have the site available again soon. Thanks. "
PS AC above, nice time machine you have... ;-)
Yep, I posted it as a comment, but it wasn't published.
Actually, this kind of security stuff (i.e. preventing SQL injection attacks) really IS easy, for anybody with half a brain cell.
The fact that you seem to think otherwise suggests that you aren't qualified to be contributing to this comments section.
Not just easy to avoid - avoidable by basic good practice
Even building SQL in your server side scripts (dodgy), the most basic input validation you should be employing simply to prevent your lusers generating errors with sloppy input / half baked urls will hose most injection attacks
i.e. your script should (even on a secure intranet and working on non-critical data)
1. enforce data type validation
2. truncate input strings of over 'n' characters
3. escape 'escape' characters (or filter them out) as appropriate
That these are not in place demonstrates lack of the most fundamental competencies.
Paris - because she regularly demonstrates a fundamental competency.
is it just me....
or can anyone else still read the obfuscated passwords in the smaller pic?
I really really REALLY hope you don't ever do any work that involves databases and the web. SQL injection attacks are THE best known, and most common web vulnerability. In most cases, it is trivial to sanitise ones database inputs e.g. if parsing a parameterised string into a database as the contents of a field, replace all single quotes with escaped ones - of course this varies with database back end and there may be other things that need to be escaped. Any programmer worth their salt would already be doing so without even thinking about it, particularly since it is the sort of thing that tends to get stressed quite heavily on any university level comp-sci course, web security seminar, etc. Most modern web-based languages provide functions that will do this for you as part of the language (PHP and PERL are two that spring to mind), so there really is no excuse.
Personally, if I were running a web site that points to any sort of database (I'm not, but I do do a lot of database work, and the same principle applies to any front-end on a database), if a SQL injection vulnerability were discovered, the first thing I would do is to take the entire site down. The second thing would be to find the programmer responsible and re-educate them BOFH style.
the website reflects poorly on Parliament ?
No, the website reflects poorly on the people who designed and configured the web site. What are their names again?, just so as we can avoid them ...
Easy != Simple
It's easy to fix a single page that contains a SQLi vulnerability. It's reasonably easy to ensure that a new web site being built from scratch won't contain this type of vulnerability, though this can get tricky if there's a large team of programmers involved - you'll need some decent QA tools.
Now, what if you take over a large, complex web site with many hundreds of pages, lousy or absent documentation and poor structuring. Still think it's trivial to eliminate all input sanitisation errors? If you do, I hazard a guess that you've never been in this position.
Whatever about SQL injection and password strength enforcements, passwords should not be stored in clear text.
I would have thought that fcking obvious to anyone with half a brain.
Burn them! Burn them all!
grep mysql_query `find . -type f `
or the relevant languages, that 2000 pages checked for fo code vulnerable to SQLi vulnerabilities, protecting against displaying XSS output, that's a lot more tricky.
Once Upon A Time
It was the business of computer departments with committed staff, and the idea, especially in public organisations, of long-term employment.
Then the idiots in coloured shirts with white cuffs and collars came along.
Time for a *complete* culture change.
Someone this lax on security probably just "borrowed" the css from another site and didn't take the name out.