Re: [html5] Input attributes allow form tampering

On Wed, 2011-08-03 at 22:56 +0000, Ian Hickson wrote:
> On Wed, 3 Aug 2011, Philippe De Ryck wrote:
> > On Tue, 2011-08-02 at 21:50 +0000, Ian Hickson wrote:
> > > On Tue, 2 Aug 2011, Philippe De Ryck wrote:
> > > >
> > > > The new form attributes, which can be used with submit buttons, can 
> > > > make it difficult for a user to distinguish the form that is being 
> > > > submitted. This can be used by an adversary to trick the user into 
> > > > submitting a form, such as an autocompleted login form. Even though 
> > > > this attack was already possible with JavaScript enabled, this new 
> > > > vector does not depend on scripts. Additionally, it is possible that 
> > > > current content validation filters do not yet prevent against button 
> > > > injection.
> > > 
> > > Surely this was already possible by just injecting </form><form 
> > > action...> in the same place as the button would be inserted today?
> > 
> > It is indeed very likely that form injection would also be possible. The 
> > difference however is that by injecting a button, you can trick the user 
> > into submitting a form that is located somewhere else on the page.
> 
> Oh, my apologies. I misunderstood. I thought you meant the new formaction, 
> etc, attributes, not the new "form" attribute.
> 
> So the attack you are concerned about is that a page that has both a form 
> for sensitive information and an area with user-generated content could be 
> attacked such that a victim is convinced to enter the sensitive 
> information in the form, and then convinced to submit the form using a 
> button elsewhere on the page, which, through the use of both the form="" 
> attribute and the formaction="" attribute, can then result in the form 
> information being sent to a different origin?

Yes exactly.

> I always hesitate to minimise the risk in security risk assessments, but 
> this does seem somewhat convoluted. Are you aware of any page that has 
> such a form, accepts user input, and uses a blacklist rather than whitelist,
> and allows <button> or <input> to be inserted unescaped but not <script>?

Your requirements for a successful attack are rather strict, since the
absence
of a script injection attack does not seem necessary. A site vulnerable
to injection attacks can still be protected against XSS by additional
countermeasures (e.g. NoScript), yet remain vulnerable to this issue

If you leave these requirements out, you only need a page with a form
and displayed user content, which is vulnerable to an HTML/script
injection attack. Concrete example sites are any site with
user-generated content (blogs, newspapers with comments, wiki's) and a
login form (which is often autocompleted by the browser). Tempting the
user to click an injected button with "Some really tempting name or
image" should be fairly easy.


-- 
Philippe De Ryck
K.U.Leuven, Dept. of Computer Science



Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Received on Thursday, 4 August 2011 13:00:36 UTC