[Tizen Application-dev] A simple SMS Reader App

Pierce, Dean E dean.e.pierce at intel.com
Fri Apr 13 22:28:24 GMT 2012

First of, that article is awesome :-D  It's super easy to read,
understand, and go through.  It was actually the first time I broke
out the SDK and got something real done, and you stepped through
everything at just the right pace.  I can't thank you enough for
writing it.

There is a really huge problem though.

Try sending a text message with the text of
"<script>alert('yay!')</script>".  I'm not sure how familiar you are
with xss, but this is a modern day example, and when xss is run in
webruntimes, the potential threat is a lot more extreme than you might
realize.  What it does is give an attacker complete control of your
app, giving it all the permissions offered in the config.xml, the
ability to attack other apps on the system, and assuming there is a
bug or two in webkit (or any of the native components the js can
touch), the attacker has the ability to break out of the wrt entirely.
(Remember a couple weeks ago when someone was asking for shell access
via javascript?  This is exactly the reason why I strongly objected)

In this particular case, the bug is in main.js

** everyone follow along, this is really important **

In seeMessageContent(), you have this message_thread, and at some
point, you start using append() to write html directly into the
object.  The problem here is that you sending in
message[i].body.plainBody, which is a string that is controlled by
someone outside of your domain (the person who sent you the txt).
They can now write directly into your dom, including the addition of
<script> tags.

I just have a passing understanding of this particular technology, but
my solution (stolen from
was to wrap the string in

$('<div/>').text( scary_string_here ).html();

so it ended up looking like

$('<div/>').text( message[i].body.plainBody ).html()

I am actually giving a talk on exactly these issues at the tizen
conference in a couple weeks.  To do this right *every single string*
that is sourced from some other domain must be *properly* filtered.  I
predict that these types of attacks will be used in nearly all
exploitation of tizen devices in the wild.  This is the way our
development process is designed, and it makes it painfully easy to
fall into this trap.

The most important message from me is that these are not developer
problems.  These are SDK and API problems.  Developers should not be
able to make mistakes like this.  We should be enforcing proper usage
of widgets for all UI styling and manipulation.  Then we can make sure
we filter properly at the widget level (setText() vs setHTML() etc).
The API also should be guiding users towards the right way of doing
things, and yelling at developers when they make mistakes like that,
though I understand that detecting that sort of thing is a non-trivial

Guilherme, thanks again for your awesome article.  I know that the app
is just a simple proof of concept, and not intended for worldwide
deployment, so I hope you aren't offended by anything I said.  Your
article is the clearest tutorial I have seen so far, so it is highly
likely that it will get a ton of views, and copy/pasted infinitely
into the future.  As such, could you please make sure you escape that
data in your code in the post, and in the repo?  Also, at the proper
point in the article, could you write a little blurb about the
importance of filtering any foreign data before placing it into the
dom?  Hopefully that will implant something in your reader's minds
that there is danger lurking, and devs need to be extremely careful
with injecting strings directly into the dom.  Thanks :-)

   - DEAN

More information about the Application-dev mailing list