Infowindows and Cross-Site Scripting (XSS) attacks
130 views
Skip to first unread message
Joseph Elfelt
Feb 27, 2011, 3:00:03 PM2/27/11
to Google Maps JavaScript API v3
Recently I asked if the content of an infowindow could be the source
of a malware attack on the user. This is an issue for me since I
have an app that allows anyone to write infowindow content which then
might be viewed by anyone else. If Ms. Black Hat writes infowindow
content that contains malware and then that infowindow is viewed by
Mr. White Hat, then White Hat is going to blame me (the author of the
app that displayed the infowindow) when bad things happen.
In response to my question, Ben pointed out that infowindows can be
used for Cross-Site Scripting (XSS) attacks. See this thread:
http://groups.google.com/group/google-maps-js-api-v3/browse_thread/thread/ab82dc1821f55fe6#
Oddly enough, this important issue has received little-to-no mention
either in the Google documentation or in this forum.
Since I want the infowindow authors to be able to use HTML and inline
CSS to style their content, I obviously needed to learn more about XSS
and how to make my app safe. After just a modest bit of reading and a
minor amount of experimentation I have reached the unsettling
conclusion that it is painfully easy to write content for an
infowindow that executes on the client computer any javascript I care
to write. <== You better read this again.
I struggled with whether I should post the code but I just can’t bring
myself to do it.
Next, I will tell you a bit more about my app since this will help you
understand if your app is at risk. My app is Gmap4 and I refer to it
rather grandly as an “enhanced Google map viewer”. Gmap4 can read and
display various kinds of files that are prepared by anyone and hosted
anywhere online. Here is a link that will open Gmap4 and display a
tab-delimited file:
http://www.mappingsupport.com/p/gmap4.php?q=https://sites.google.com/site/gmap4files/p/tab/teanaway_peaks_tab.txt&label=yes
If you click a marker, then an infowindow appears. But I do not write
that infowindow content. Anyone at all can prepare a tab-delimited
file (with the required layout) and invite other people to view that
file (and click on its markers) with my app.
If you have an app where neither you nor a trusted associate prepared
the infowindow content, then your app is at risk of being used by a
Black Hat to perform XSS attacks on your users.
After some more reading and pondering I have implemented a ‘black
list’ in my app. If any of the following strings appear anywhere in
the tab-delimited file, then my app displays an error message and
stops. The map never appears on the user’s screen and thus the user
never has a chance to click a marker that might cause malware to be
executed. My blacklist is presently:
script, expression, iframe, .swf and .exe
I selected a ‘black list’ approach since this type of attack is known
as “DOM Based XSS” and apparently is rare in the wild. In other
words, I implemented a quick and easy solution for a problem that is
not currently widespread. However, if this type of XSS attack becomes
a significant problem then I may learn how to us this:
http://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project
Also, perhaps Google would consider taking the code it uses to scan
KML files and making it available to us in a library.
And speaking of KML files, I put my XSS code into an infowindow
description within a KML file and tried to display that file with my
app. Good news - the user (me in this test case) was protected from
my XSS attack. Bad news - my screen remained mostly blank. It would
be more user-friendly if Google’s map API returned some kind of error
code which my app could use as the basis for displaying a message to
Mr. White Hat who is busy cussing my worthless app which refuses to
display the (infected) KML file he asked to view.
Further reading:
http://www.owasp.org/index.php/DOM_Based_XSS
http://www.owasp.org/index.php/Testing_for_DOM-based_Cross_site_scripting_%28OWASP-DV-003%29
http://www.webappsec.org/projects/articles/071105.shtml (2005 article)
of a malware attack on the user. This is an issue for me since I
have an app that allows anyone to write infowindow content which then
might be viewed by anyone else. If Ms. Black Hat writes infowindow
content that contains malware and then that infowindow is viewed by
Mr. White Hat, then White Hat is going to blame me (the author of the
app that displayed the infowindow) when bad things happen.
In response to my question, Ben pointed out that infowindows can be
used for Cross-Site Scripting (XSS) attacks. See this thread:
http://groups.google.com/group/google-maps-js-api-v3/browse_thread/thread/ab82dc1821f55fe6#
Oddly enough, this important issue has received little-to-no mention
either in the Google documentation or in this forum.
Since I want the infowindow authors to be able to use HTML and inline
CSS to style their content, I obviously needed to learn more about XSS
and how to make my app safe. After just a modest bit of reading and a
minor amount of experimentation I have reached the unsettling
conclusion that it is painfully easy to write content for an
infowindow that executes on the client computer any javascript I care
to write. <== You better read this again.
I struggled with whether I should post the code but I just can’t bring
myself to do it.
Next, I will tell you a bit more about my app since this will help you
understand if your app is at risk. My app is Gmap4 and I refer to it
rather grandly as an “enhanced Google map viewer”. Gmap4 can read and
display various kinds of files that are prepared by anyone and hosted
anywhere online. Here is a link that will open Gmap4 and display a
tab-delimited file:
http://www.mappingsupport.com/p/gmap4.php?q=https://sites.google.com/site/gmap4files/p/tab/teanaway_peaks_tab.txt&label=yes
If you click a marker, then an infowindow appears. But I do not write
that infowindow content. Anyone at all can prepare a tab-delimited
file (with the required layout) and invite other people to view that
file (and click on its markers) with my app.
If you have an app where neither you nor a trusted associate prepared
the infowindow content, then your app is at risk of being used by a
Black Hat to perform XSS attacks on your users.
After some more reading and pondering I have implemented a ‘black
list’ in my app. If any of the following strings appear anywhere in
the tab-delimited file, then my app displays an error message and
stops. The map never appears on the user’s screen and thus the user
never has a chance to click a marker that might cause malware to be
executed. My blacklist is presently:
script, expression, iframe, .swf and .exe
I selected a ‘black list’ approach since this type of attack is known
as “DOM Based XSS” and apparently is rare in the wild. In other
words, I implemented a quick and easy solution for a problem that is
not currently widespread. However, if this type of XSS attack becomes
a significant problem then I may learn how to us this:
http://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project
Also, perhaps Google would consider taking the code it uses to scan
KML files and making it available to us in a library.
And speaking of KML files, I put my XSS code into an infowindow
description within a KML file and tried to display that file with my
app. Good news - the user (me in this test case) was protected from
my XSS attack. Bad news - my screen remained mostly blank. It would
be more user-friendly if Google’s map API returned some kind of error
code which my app could use as the basis for displaying a message to
Mr. White Hat who is busy cussing my worthless app which refuses to
display the (infected) KML file he asked to view.
Further reading:
http://www.owasp.org/index.php/DOM_Based_XSS
http://www.owasp.org/index.php/Testing_for_DOM-based_Cross_site_scripting_%28OWASP-DV-003%29
http://www.webappsec.org/projects/articles/071105.shtml (2005 article)
JKurtock
Feb 27, 2011, 7:07:54 PM2/27/11
to Google Maps JavaScript API v3
I don't claim to be a security expert, but I do know:
Allowing ".. authors to be able to use HTML and inline
CSS to style their content, ..."
is suicide, and a "black list" approach is merely announcing to the
world that you think you are smarter than Ms. BlackHat. With
predictable results.
On Feb 27, 12:00 pm, Joseph Elfelt <josephelf...@gmail.com> wrote:
> Recently I asked if the content of an infowindow could be the source
> of a malware attack on the user. This is an issue for me since I
> have an app that allows anyone to write infowindow content which then
> might be viewed by anyone else. If Ms. Black Hat writes infowindow
> content that contains malware and then that infowindow is viewed by
> Mr. White Hat, then White Hat is going to blame me (the author of the
> app that displayed the infowindow) when bad things happen.
>
> In response to my question, Ben pointed out that infowindows can be
> used for Cross-Site Scripting (XSS) attacks. See this thread:http://groups.google.com/group/google-maps-js-api-v3/browse_thread/th...
> Further reading:http://www.owasp.org/index.php/DOM_Based_XSShttp://www.owasp.org/index.php/Testing_for_DOM-based_Cross_site_scrip...http://www.webappsec.org/projects/articles/071105.shtml (2005 article)
Allowing ".. authors to be able to use HTML and inline
CSS to style their content, ..."
is suicide, and a "black list" approach is merely announcing to the
world that you think you are smarter than Ms. BlackHat. With
predictable results.
On Feb 27, 12:00 pm, Joseph Elfelt <josephelf...@gmail.com> wrote:
> Recently I asked if the content of an infowindow could be the source
> of a malware attack on the user. This is an issue for me since I
> have an app that allows anyone to write infowindow content which then
> might be viewed by anyone else. If Ms. Black Hat writes infowindow
> content that contains malware and then that infowindow is viewed by
> Mr. White Hat, then White Hat is going to blame me (the author of the
> app that displayed the infowindow) when bad things happen.
>
> In response to my question, Ben pointed out that infowindows can be
> Oddly enough, this important issue has received little-to-no mention
> either in the Google documentation or in this forum.
>
> Since I want the infowindow authors to be able to use HTML and inline
> CSS to style their content, I obviously needed to learn more about XSS
> and how to make my app safe. After just a modest bit of reading and a
> minor amount of experimentation I have reached the unsettling
> conclusion that it is painfully easy to write content for an
> infowindow that executes on the client computer any javascript I care
> to write. <== You better read this again.
>
> I struggled with whether I should post the code but I just can’t bring
> myself to do it.
>
> Next, I will tell you a bit more about my app since this will help you
> understand if your app is at risk. My app is Gmap4 and I refer to it
> rather grandly as an “enhanced Google map viewer”. Gmap4 can read and
> display various kinds of files that are prepared by anyone and hosted
> anywhere online. Here is a link that will open Gmap4 and display a
> tab-delimited file:http://www.mappingsupport.com/p/gmap4.php?q=https://sites.google.com/...
> either in the Google documentation or in this forum.
>
> Since I want the infowindow authors to be able to use HTML and inline
> CSS to style their content, I obviously needed to learn more about XSS
> and how to make my app safe. After just a modest bit of reading and a
> minor amount of experimentation I have reached the unsettling
> conclusion that it is painfully easy to write content for an
> infowindow that executes on the client computer any javascript I care
> to write. <== You better read this again.
>
> I struggled with whether I should post the code but I just can’t bring
> myself to do it.
>
> Next, I will tell you a bit more about my app since this will help you
> understand if your app is at risk. My app is Gmap4 and I refer to it
> rather grandly as an “enhanced Google map viewer”. Gmap4 can read and
> display various kinds of files that are prepared by anyone and hosted
> anywhere online. Here is a link that will open Gmap4 and display a
Esa
Feb 27, 2011, 7:51:47 PM2/27/11
to Google Maps JavaScript API v3
> Oddly enough, this important issue has received little-to-no mention
> either in the Google documentation or in this forum.
Because that has nothing to do with the subject of this forum.
> either in the Google documentation or in this forum.
This is a forum for Google Maps JavaScript API v3. Not about secure
html forms.
Chris Broadfoot
Feb 28, 2011, 3:32:27 AM2/28/11
to google-map...@googlegroups.com, Esa
On Mon, Feb 28, 2011 at 11:51 AM, Esa <esa.i...@gmail.com> wrote:
Because that has nothing to do with the subject of this forum.
This is a forum for Google Maps JavaScript API v3. Not about secure
html forms.
That said, do you need to secure against XSS attacks? Do you have cookies/user data hosted on mappingsupport.com?
Joseph Elfelt
Feb 28, 2011, 8:28:50 AM2/28/11
to Google Maps JavaScript API v3
On Feb 28, 12:32 am, Chris Broadfoot <c...@google.com> wrote:
> That said, do you need to secure against XSS attacks? Do you have
> cookies/user data hosted on mappingsupport.com?
No, mappingsupport.com does not create any cookies and does not
> That said, do you need to secure against XSS attacks? Do you have
> cookies/user data hosted on mappingsupport.com?
collect or store any user data.
Question: Does anyone know of instances where Google map infowindows
been used for malicious XSS attacks?
I suspect that it is people that post in this forum that are the ones
most likely to know the answer.
Reply all
Reply to author
Forward
0 new messages