This is part 2 of a series of blog posts looking at the security of the UK Government's web infrastructure.
Many XSS flaws rely on altering the GET parameters of a request. Some webmasters seem to think that if their forms only use POST they will be immune from the XSS. This is not the case.
Don't Press This Button
Pressing this button will send a POST request to the Department of Education's EduBase website.
Up until yesterday, the site would blindly echo back anything that was sent to it. Which resulted in the page looking something like this:
Code
HTML forms can direct your browser to POST information to any site. It's even possible to hide the data from the user - so all they see is a big button to press.
<form method="post"
id="quickSearch"
action="http://www.education.gov.uk/edubase/home.xhtml" >
<input id="establishmentName.value"
name="establishmentName.value"
type="hidden"
value="<h1>XSS Demonstration</h1>
<h2><a href='http://www.teachers.org.uk/campaigns/protect-teachers'>Demo link</a></h2>
<img src='https://gs1.wac.edgecastcdn.net/8019B6/data.tumblr.com/tumblr_m811uzuyp91rcq3oko1_500.jpg'/><br />
<script>alert('JavaScript XSS');</script>"
/>
<button>Demonstrate XSS</button>
</form>
Mitigation
Always escape untrusted data! Read the OWASP cheat sheet for more information.
When such a flaw is discovered and then reported, it is imperative that you have a plan to rapidly secure it. It took 27 days to get the fix into production. I've no idea how long it was open for - or how many people exploited it in that time.
In this case, the Department for Education have outsourced EduBase to Texuna - a technology partner. Texuna don't have any secure way for people to report flaws to them and, when notified, struggled to find someone who could take responsibility.
Texuna seemed to me unable to convey the urgency of the situation to the DfE. A complicated public/private partnership with multiple stakeholders seems to mean that there is no way to escalate security issues.
While it is vitally important to thoroughly test security patches, there's also a very real risk involved in leaving a system unpatched.
This is a textbook example of where outsourcing fails. The ideological agenda which promotes the lowest bidder is doomed to failure when a crisis occurs. Responsibility is diffused, no one is empowered to make decisions, and without proper management oversight critical bugs are left unfixed.
Compare and contrast to yesterday's bug. An identical XSS bug in the Parliament.uk website was fixed over a weekend. Because the Parliament team was centralised and highly motivated they were able to accomplish something a "highly trusted partner" could not.
It is not known how many more of Texuna's client's sites are in a similarly unsecured state.
Timeline
- 5th February. Disclosed to Department of Education and their technology partner Texuna.
- 7th February. Disclosed to GovCertUK.
- 12th February. Contacted the TES Newspaper to allow them to report on the story.
- 26th February. According to Texuna a fix released - to be scheduled for production "soon".
- 28th February. Informed Texuna of publication date.
- 3rd March. Fixed.
- 4th March. Published.
A Special Message For Michael Gove
I think you've over-stated the outsourcing element. Lack of escalation process and/or ownership (and problems responding to emergencies) isn't unique to outsourced systems and the result is the same regardless.
It can certainly be a problem with internal teams. But I've never seen an outsourced team which has the same level of access to decision making members of staff in the "parent" organisation.
Additionally, outsourced partners are - in my experience - much more concerned about hitting contractual metrics rather than solving problems. Sometimes that works - often it doesn't.
'Solving problems' is a pretty good contractual metric, but it may also be that the customer here just doesn't think it's a good cost / benefit to pay for greater agility*.
* Guessing, I have no knowledge of this site or supplier.