maxlength on input box can be overriden by autocomplete

Bug #486284 reported by arnaldoestevao on 2009-11-21
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
Medium
firefox (Ubuntu)
Low
Unassigned
firefox-3.5 (Ubuntu)
Low
Unassigned

Bug Description

Binary package hint: firefox-3.0

<input type=text name=name maxlength=10>

only typed data was blocked, if data has previous memorized in form data cache ,
firefox allow string with more characters then maxlength value

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
NonfreeKernelModules: wl
Package: firefox-3.0 3.0.15+nobinonly-0ubuntu0.9.04.1
ProcEnviron:
 LANG=pt_BR.UTF-8
 SHELL=/bin/bash
SourcePackage: firefox-3.0
Uname: Linux 2.6.28-16-generic i686

Created an attachment (id=323854)
maxlength test

No, not a dupe. It's asking (without providing any reason other than Fx2-compat) that bug 345267 be reverted. Assuming the comments there are correct, and the current behavior is the same as every other browser except Fx2, it's a wontfix.

Indeed.

It's just strange behaviour for javascript to not respect html when the DOM is modified. Are there any official specifications on how this should actually work - rather than saying "other browsers do it like that"? If this mentality is used, then we'd have to duplicate all IE quirks as it's how the other half of the world is doing it.

> Are there any official specifications on how this should actually
> work - rather than saying "other browsers do it like that"?

Not yet. HTML5 is specifying this behavior (and Firefox 3 is following the draft HTML5 spec).

> then we'd have to duplicate all IE quirks

We basically do duplicate all the IE quirks that don't violate existing specifications and are needed to make significant numbers of existing web sites work... So do all the other browsers.

User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9) Gecko/2008052912 Firefox/3.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9) Gecko/2008052912 Firefox/3.0

It is possible to bypass the maximum length limitation for text input fields with autocomplete. Autocomplete offers any text, even if it's longer than what is allowed and the field is consequently populated after selecting the too long text.

Reproducible: Always

Steps to Reproduce:
1. Create a new html file with following content in the body:
<form id="testForm" method="GET">
 <input id="testInput" type="text" />
 <input type="submit" />
</form>
2. Open the file in the browser and type "0123456789" in the input field and hit submit.
3. Change the file and add 'maxlength="5"' to the input field.
4. Go back to the browser and refresh.
Actual Results:
Now it is possible to select "0123456789" as value for the input field.

Expected Results:
Autocomplete should not render suggestions that are longer than _maxlength_ or when such a value is selected, it should be trimmed to a total length of _maxlength_.

I believe this is quite a critical issue, as most developers rely on the size of the strings that are provided by the limited input fields. That is - many applications probably would behave in an unexpected manner, when provided with longer texts.

Hunh - no doubt about it, confirmed via data url.

I don't think this needs to be hidden, there are plenty of ways to get around maxlength parameters and they aren't something web developers should ever rely on as a safety mechanism; they only keep honest people honest, basically. The exploit possibilities seem somewhat remote, and only make slightly more visible an existing vulnerability in the target website (i.e. relying on maxlength).

Nevertheless, we should fix it, and I'm surprised it hasn't come up earlier, but I'm not having any luck finding an existing bug. Bug 204506 is similar, but clearly didn't fix this problem. Bug 443363 is a dup of this bug.

*** Bug 443363 has been marked as a duplicate of this bug. ***

This is a regression from Firefox 2.0.0.x which correctly truncates the autocomplete data at the maxlength.

> I believe this is quite a critical issue, as most developers rely on
> the size of the strings that are provided by the limited input fields.

That would be unwise. Hackers are not constrained by the maxlength limit and would love to find that exceeding it throws your server for a loop.

Mike: did anyone re-work autocomplete for FF3? I assume the awesomebar is its own thing and not built on autocomplete but that could be wrong.

The autocomplete code doesn't do anything special related to maxlength, so this was probably caused by bug 345267. That change made it possible to enter more than maxlength characters into a text field programmatically, to match other browsers. The autocomplete code sets the value via the same code path as page scripts, so it was affected too.

Boris, can you look at this?

This needs a fix on the autocomplete side: it needs to be checking the maxlength. It didn't need to before, as Gavin said, because it was relying on a core bug. Then we fixed the core bug.

*** Bug 452365 has been marked as a duplicate of this bug. ***

Created an attachment (id=335666)
WIP

I put this together a while ago but couldn't get the test to work. The entries added by the test are apparently not added correctly because they don't appear as options, and even if they did I'm not sure that the code I use to select the autocomplete entry will work.

*** Bug 453815 has been marked as a duplicate of this bug. ***

*** Bug 451396 has been marked as a duplicate of this bug. ***

*** Bug 485710 has been marked as a duplicate of this bug. ***

Created an attachment (id=389264)
v.1 only show entries that fit (applies to patch v.3 on bug 446247)

Instead of truncating, only show form history entries that will fit in the field.

(From update of attachment 389264)
>+ if (aField && aField.maxLength > -1)
>+ result.wrappedJSObject.entries = result.wrappedJSObject.entries.filter(this._filterEntryLength, aField);

Use an inline anonymous function here...

foo = foo.filter(function (e) { return (element.text.length <= this.maxLength) });

(A refinement of having a local function in the if-block to do this, which would be my choice instead of having a tiny utility function stuck, at distance, onto the component's object).

Created an attachment (id=390343)
v.2 inline function & update unit tests

(From update of attachment 390343)
sr? for API change, this was added in 3.6 so there's no compat issues.

Created an attachment (id=390676)
v.3 fix bitrot

(From update of attachment 390676)
sr=mconnor

*** Bug 510355 has been marked as a duplicate of this bug. ***

verified with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b1pre) Gecko/20090925 Namoroka/3.6b1pre

*** Bug 521310 has been marked as a duplicate of this bug. ***

Binary package hint: firefox-3.0

<input type=text name=name maxlength=10>

only typed data was blocked, if data has previous memorized in form data cache ,
firefox allow string with more characters then maxlength value

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
NonfreeKernelModules: wl
Package: firefox-3.0 3.0.15+nobinonly-0ubuntu0.9.04.1
ProcEnviron:
 LANG=pt_BR.UTF-8
 SHELL=/bin/bash
SourcePackage: firefox-3.0
Uname: Linux 2.6.28-16-generic i686

security vulnerability: yes → no
visibility: private → public
Micah Gersten (micahg) wrote :

Thanks for reporting this bug and any supporting documentation. Since this bug has enough information provided for a developer to begin work, I'm going to mark it as Triaged and let them handle it from here.
I am moving this to Firefox 3.5 as 3.0 will be EOL next month and this is a low priority issue. Thanks for taking the time to make Ubuntu better! Please report any other issues you may find.

affects: firefox-3.0 (Ubuntu) → firefox-3.5 (Ubuntu)
Changed in firefox-3.5 (Ubuntu):
importance: Undecided → Low
status: New → Triaged
Micah Gersten (micahg) wrote :

I think I was too hasty here. My test case was for javascript overriding maxlength, but I found https://bugzilla.mozilla.org/show_bug.cgi?id=437379 which rejected that as a bug. Could you please give up steps to reproduce the case you are thinking of?

Changed in firefox-3.5 (Ubuntu):
status: Triaged → Incomplete
Micah Gersten (micahg) wrote :

Nevermind, I found the upstream bug which seems to be what you were describing. Take a look and if it's not, let us know. This is scheduled to be fixed in Firefox 3.6
Please report any other bugs you may find.

Changed in firefox-3.5 (Ubuntu):
status: Incomplete → Triaged
Changed in firefox:
status: Unknown → Fix Released
Micah Gersten (micahg) on 2009-11-24
summary: - maxlength not stop long values
+ maxlength on input box can be overriden by autocomplete

" - maxlength not stop long values
+ maxlength on input box can be overriden by autocomplete "

ok, i tryed say just this !

not problem with javascript only with autocomplete , javascript ist a choice of programmer, but auto complete its a feature of Firefox , i think that can not overriden forms restrictions , or will allow wrong datas to be input , auto-complete need respect maxlength value

sorry for my bad english i am brasilian and are very hard to me explain the problem ,

*** Bug 532151 has been marked as a duplicate of this bug. ***

Micah Gersten (micahg) on 2009-12-21
Changed in firefox:
milestone: none → 3.6

*** Bug 537079 has been marked as a duplicate of this bug. ***

Micah Gersten (micahg) wrote :

firefox will be the source package for Firefox 3.6, so adding this task

Changed in firefox (Ubuntu):
importance: Undecided → Low
status: New → Triaged
Launchpad Janitor (janitor) wrote :
Download full text (9.6 KiB)

This bug was fixed in the package firefox - 3.6+nobinonly-0ubuntu1

---------------
firefox (3.6+nobinonly-0ubuntu1) lucid; urgency=low

  * New upstream release v3.6 (FIREFOX_3_6_RELEASE)
    + fix LP: #449744 - Firefox crashes when attempting to load Firebug 1.5
    + fix LP: #66015 - Duplicate spell checking dictionaries for every entry
    + fix LP: #132938 - tooltips dont work in sidebar
    + fix LP: #195698 - Password asked separately for each tab that requires it
                        (proxy)
    + fix LP: #239462 - tooltips disappear too fast
    + fix LP: #385816 - Resize corner grab stays visible after maximize
    + fix LP: #429476 - firefox crash on javascript page
    + fix LP: #432876 - Icons missing in Firefox searchbox drop down list
    + fix LP: #486284 - maxlength on input box can be overriden by autocomplete
    + fix LP: #501393 - Integrate Firefox notifications with notify-osd bling

  [ H. Montoliu <email address hidden> ]
  * fix LP: #361052 - firefox apport hook fails to retrieve pluginreg.dat file
  * update debian/apport/firefox-3.6.py - removed unused code and minor refactoring.

  [ Fabien Tassin <email address hidden> ]
  * Update the location of the upsteam branch now that 3.6/Namoroka has its own
    branch, and trunk moved on to 3.7
    - update debian/mozclient/firefox-3.6.conf
  * Use Namoroka instead of Shiretoko as brand name and use it for snapshots.
    Name it Namoroka in the Preferred Application UI too
    - update debian/firefox-3.6-shiretoko.desktop => debian/firefox-3.6-namoroka.desktop
    - update debian/firefox-3.6.xml
    - update debian/rules
  * Target the 'default' branch instead of tip
    - add debian/moz-rev.sh
    - update debian/mozclient/firefox-3.6.conf
  * Add firefox 3.6 to the list of Preferred Applications in Gnome
    - add debian/firefox-3.6.xml
    - update debian/firefox-3.6-gnome-support.install
  * Add ${misc:Depends} to all non-transitional packages, make firefox-3.6-dbg
    depend on firefox-3.6 with the exact same version, move -dbg packges to
    priority extra and add firefox-3.6-gnome-support-dbg
    - update debian/control
  * Update diverged patches:
    - update debian/patches/browser_branding.patch
    - update debian/patches/firefox-profilename
    - update debian/patches/ubuntu_bookmarks.patch
    - update debian/patches/lp185622_system_path_default_browser.patch
    - update debian/patches/dont_depend_on_nspr_sources.patch

  [ Alexander Sack <email address hidden> ]
  * add libnotify-dev to build-depends
    - update debian/control
  * add libiw-dev to build-depends to fix build failure
    - update debian/control
  * until we move searchplugins to a separate package provided only by the current default
    firefox, we need to make firefox-3.6 replace all the older firefox binary packages:
    firefox-3.5, firefox-3.2, firefox-3.1, firefox-3.0
    - update debian/control
  * implement MIN_SYS_DEPS approach that does not use system xulrunner
    and only a minimal set of system dependencies.
    + drop patches not required anymore:
      - delete debian/patches/dont_depend_on_nspr_sources.patch
      - update debian/patches/series
    + update browser directory provider...

Read more...

Changed in firefox (Ubuntu):
status: Triaged → Fix Released

*** Bug 546618 has been marked as a duplicate of this bug. ***

*** Bug 571889 has been marked as a duplicate of this bug. ***

Changed in firefox:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.