529676 - I can modify non-editable html content through specific keyboard+mouse keystrokes

Status: RESOLVED DUPLICATE of bug 424627

(Core :: DOM: Core & HTML, defect)

Description

[pablodg]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)

 

Reproducible: Always

Comment 1

[Reed Loden [:reed]]

Do you have a testcase you could provide us?

Comment 2

[pablodg]

Attachment: Steps to reproduce the bug using windows XP at mozilla's site.

Comment 3

[pablodg]

Sorry it submitted before I finished details. I am adding an attachment on how to reproduce the behavior on the mozilla add new bug page. I can also be reproduced on googles home page, where it allows to add text on the page.

The steps are:
1. In windows, put the caret (mouse pointer) one pixel after the left border of a textbox.
2. Press ctrl+click
3. Paste text using ctrl+c (ej. some thumg phrase you have prepared for the occasion).

This implies a security concern as it is html injection (ej. users can remove mandatory fields from forms).

Comment 4

[pablodg]

Attachment: Mozilla-Google home page modified using this html injection issue

Comment 5

[pablodg]

(In reply to comment #1)
> Do you have a testcase you could provide us?

Yes. I have now submitted the right information so that it can be fixed.

Comment 6

[pablodg]

Attachment: By replacing text, I arrived to bound textbox to panel

When you type or remove text in the textbox, the title panel gets updated with the content of the textbox. Even when I am an advanced C++ programmer, I find this really crazy (I first though it was a virus on my computer, but I checked many places and it is definitely a security bug).

Comment 7

[Daniel Veditz [:dveditz]]

Definitely a bug, but hard to call a security bug if the user is doing it to themselves. Could be a problem for a server, but the server can't ever trust a client because if it really is a hacker they could be using any tool they like to make changes before submitting forms.

Comment 8

[pablodg]

I have hesited too. But as it makes it so much easy to post an altered form to a server, I think is creates a security concern. 

It is true that a hacking tool can be used to do the same to a server, but inside a company where they use Firefox in their intranets, they certainly do not expect Firefox to be so easly used as a hacking tool. Network administrators can control their employees not to enter hacking tools into their they PCs [no usb drives, no downloads] but they cannot keep them from using Firefox if it is installed. That's why I believe it creates a security concern for intranet forms (and of course, because I want my t-shirt!!! =) ).

In case you will still classify this as a non-security issue, please let me know as I wish to freely publish it as a 'non-classified' 'feature'.


(In reply to comment #7)
> Definitely a bug, but hard to call a security bug if the user is doing it to
> themselves. Could be a problem for a server, but the server can't ever trust a
> client because if it really is a hacker they could be using any tool they like
> to make changes before submitting forms.

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

Security-vise, how is this any worse than just modifying the currently loaded 
page using the following javascript url:
javascript:document.body.contentEditable = true; void(0);
Once user has modified the page, contentEditable can be set to false.
javascript:document.body.contentEditable = false; void(0);

(Modifying a page using javascript urls is a feature, not a bug.)

Comment 10

[:Gavin Sharp [email: [e-mail]]]

related bugs: bug 462970, bug 424627

Comment 11

[Andrew Overholt [:overholt]]

(In reply to Olli Pettay [:smaug] from comment #9)
> Security-vise, how is this any worse than just modifying the currently
> loaded 
> page using the following javascript url:
> javascript:document.body.contentEditable = true; void(0);
> Once user has modified the page, contentEditable can be set to false.
> javascript:document.body.contentEditable = false; void(0);
> 
> (Modifying a page using javascript urls is a feature, not a bug.)

Should we WONTFIX this?

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

I don't think so. Someone needs to try to reproduce the issue (which isn't a security issue) to see if this is still an issue.
I couldn't get the case working now on linux.

Bug 424627 may have fixed this.

Comment 13

[(no longer active)]

As far as I can tell, this is literally a dupe of bug 424627.