Ubuntu
firefox-3.5 package

maxlength on input box can be overriden by autocomplete

Bug #486284 reported by arnaldoestevao
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
Medium
Mozilla Firefox 3.6
firefox (Ubuntu)
Fix Released
Low
Unassigned
firefox-3.5 (Ubuntu)
Triaged
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

See original description
Revision history for this message
In , Jairak (jairak) wrote :

Created an attachment (id=323854)
maxlength test

Revision history for this message
In , Ria-klaassen (ria-klaassen) wrote :

Duplicate of Bug 350786 ?

Revision history for this message
In , Philringnalda (philringnalda) wrote :

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.

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

Indeed.

Revision history for this message
In , Jairak (jairak) wrote :

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.

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

> 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.

Revision history for this message
In , Vassil-hristov (vassil-hristov) wrote :

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.

Revision history for this message
In , Johnath (johnath) wrote :

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.

Revision history for this message
In , Johnath (johnath) wrote :

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

Revision history for this message
In , Dveditz (dveditz) wrote :

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.

Revision history for this message
In , Gavin Sharp (gavin-sharp) wrote :

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.

Revision history for this message
In , Samuel Sidler (samuel-sidler) wrote :

Boris, can you look at this?

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

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.

Revision history for this message
In , Gavin Sharp (gavin-sharp) wrote :

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

Revision history for this message
In , Gavin Sharp (gavin-sharp) wrote :

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.

Revision history for this message
In , Jruderman (jruderman) wrote :

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

Revision history for this message
In , Ian-ithomas (ian-ithomas) wrote :

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

Revision history for this message
In , Mats Palmgren (matspal) wrote :

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

Revision history for this message
In , Mmn100+bmo (mmn100+bmo) wrote :

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.

Revision history for this message
In , Dolske (dolske) wrote :

(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).

Revision history for this message
In , Mmn100+bmo (mmn100+bmo) wrote :

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

Revision history for this message
In , Dolske (dolske) wrote :

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

Revision history for this message
In , Mmn100+bmo (mmn100+bmo) wrote :

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

Revision history for this message
In , Mike Connor (mconnor) wrote :

(From update of attachment 390676)
sr=mconnor

Revision history for this message
In , Dolske (dolske) wrote :

Pushed http://hg.mozilla.org/mozilla-central/rev/0c9d24a0f828

Revision history for this message
In , Mmn100+bmo (mmn100+bmo) wrote :

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

Revision history for this message
In , Twalker (twalker) wrote :

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

Revision history for this message
In , Mmn100+bmo (mmn100+bmo) wrote :

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

Revision history for this message
arnaldoestevao (arnaldoestevao) wrote : maxlength not stop long values

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

Revision history for this message
arnaldoestevao (arnaldoestevao) wrote :
Marc Deslauriers (mdeslaur)
security vulnerability: yes → no
visibility: private → public
Revision history for this message
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
Revision history for this message
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
Revision history for this message
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
Bug Watch Updater (bug-watch-updater)
Changed in firefox:
status: Unknown → Fix Released
Micah Gersten (micahg)
summary: - maxlength not stop long values
+ maxlength on input box can be overriden by autocomplete
Revision history for this message
arnaldoestevao (arnaldoestevao) wrote :

" - 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 ,

Revision history for this message
In , Mmn100+bmo (mmn100+bmo) wrote :

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

Micah Gersten (micahg)
Changed in firefox:
milestone: none → 3.6
Revision history for this message
In , Mmn100+bmo (mmn100+bmo) wrote :

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

Revision history for this message
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
Revision history for this message
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
Revision history for this message
In , longsonr (longsonr) wrote :

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

Revision history for this message
In , longsonr (longsonr) wrote :

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

Bug Watch Updater (bug-watch-updater)
Changed in firefox:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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