#15048 closed bug (fixed)

Opened September 16, 2016 09:35AM UTC

Closed September 22, 2016 11:54AM UTC

Last modified September 22, 2016 11:56AM UTC

XSS issue in autocomplete demo

Reported by:	wenz	Owned by:	wenz
Priority:	minor	Milestone:	1.12.2
Component:	[meta] ui.dev	Version:	1.12.1
Keywords:		Cc:
Blocked by:		Blocking:

Description

The search.php file in the autocomplete demo does not validate the value of $_GET["callback"] before outputting it, thus allowing Cross-Site Scripting.

The PR adds a simple check for alphanumeric characters and the underscore, which is what jQuery uses by default for JSONP requests.

Attachments (0)

Change History (8)

Changed September 16, 2016 09:48AM UTC by rjollos comment:1

description:	The search.php file in the autocomplete demo does not validate the value of $_GET["callback"] before outputting it, thus allowing Cross-Site Scripting. \ The PR adds a simple check for alphanumeric characters and the underscore, which is what jQuery uses by default for JSONP requests. → The `search.php` file in the autocomplete demo does not validate the value of `$_GET["callback"]` before outputting it, thus allowing Cross-Site Scripting. \ \ The PR adds a simple check for alphanumeric characters and the underscore, which is what jQuery uses by default for JSONP requests.

description:

The search.php file in the autocomplete demo does not validate the value of $_GET["callback"] before outputting it, thus allowing Cross-Site Scripting. \ The PR adds a simple check for alphanumeric characters and the underscore, which is what jQuery uses by default for JSONP requests. → The `search.php` file in the autocomplete demo does not validate the value of `$_GET["callback"]` before outputting it, thus allowing Cross-Site Scripting. \ \ The PR adds a simple check for alphanumeric characters and the underscore, which is what jQuery uses by default for JSONP requests.

Changed September 16, 2016 10:00AM UTC by jzaefferer comment:2

owner:	→ wenz
status:	new → pending

The fix looks fine to me. I'm curious: What's the attack vector here? Can you be more specific than "XSS"?

Changed September 19, 2016 01:50PM UTC by scottgonzalez comment:3

As far as I can tell, there is no real attack vector. This is just about general practices for sanitizing user input. I'm fine landing the PR, but unless someone can point out an actual security vulnerability, I don't believe there is a bug.

Changed September 21, 2016 04:51PM UTC by scottgonzalez comment:4

resolution:	→ notabug
status:	pending → closed

The team cannot figure out any actual attack vectors. The only attack vector that could occur would be on the client machine that's making the request. For our demos, there's no attack vector on that side either.

Changed September 22, 2016 05:21AM UTC by wenz comment:5

sorry for replying so late - somehow didn't get the email notifications :( Attack vector is loading search.php?term=X&callback=script_tag_with_some_code in the browser. See also the discussion for PR 1747. Please reopen!

Changed September 22, 2016 11:49AM UTC by scottgonzalez comment:6

component:	ui.autocomplete → [meta] ui.dev
resolution:	notabug
status:	closed → reopened

Changed September 22, 2016 11:54AM UTC by scottgonzalez comment:7

resolution:	→ fixed
status:	reopened → closed

In [changeset:"69e66ea6556584c39621c184f8f790a1011408ce" 69e66ea6]:

#!CommitTicketReference repository="" revision="69e66ea6556584c39621c184f8f790a1011408ce"
Autocomplete: Escape HTML tags in callback name to avoid XSS in demo

Fixes #15048

Changed September 22, 2016 11:56AM UTC by scottgonzalez comment:8

milestone:	none → 1.12.2

Search and Top Navigation