Re: A few comments on latest draft of Mobile Web Application Best Practices

Adam Connors wrote:
[...]
>     3.4.7.1 "be weighed" -> "be weighted"
> 
> i believe this is correct as is.

Well, I'm sure you're right ;)


[...]
>     3.2.1 Do not execute untrusted Javascript
>     -----
>     3.2.1.2 could perhaps mention the fact that HTTP spoofing attacks
>     are still possible. A widget would typically have access to
>     sensitive device APIs, but could still use HTTP to retrieve JSON
>     strings, so any man-in-the-middle here could gain access to the same
>     sensitive APIs in theory. This is particularly relevant to mobile
>     devices because access to the Web more and more relies on a priori
>     untrusted public Wifi networks. OK, I might have become crazy about
>     security-related topics...
> 
> 
> sounds interesting -- can you explain a little more, i'm not sure i 
> understand the issue sufficiently to write up.

I think it all boils down to fine-tuning the final paragraph in 3.2.1.2, 
or perhaps simply to remove it. There is no real good answer to 
privacy/security concerns that I'm aware of.

Anyway, let's be a bit paranoid about privacy here.

The final paragraph in 3.2.1.2 seems to say that it's OK to evaluate the 
JSON data directly, provided that the server generated the data or that 
user-generated data is escaped.

Widgets are likely to be granted some privileges to access sensitive 
information on the devices through APIs. They may use JSON to retrieve 
non-sensitive information from a server, and since that's not sensitive, 
they are not likely to use HTTPS. Let's say we have such a widget and 
that this widget follows the recommendations of the last paragraph.

Most high-end mobile devices come with Wifi, and connect through 
"insecure" access points (insecure because you usually don't know who 
controls the access point). These access points can be malicious and may 
temper with the HTTP messages that flow through them.

So, in theory, a malicious access point could tweak the JSON data sent 
to the widget and since the widget uses eval() because it thinks the 
data does not contain any user-generated content, the access point could 
inject code that would get executed under the widget's security settings 
and gain access to sensitive information.

In practice, this is very unlikely to occur and/or to work, but then it 
is still possible. Possible solutions:
- use HTTPS for all exchanges, but that looks a bit as an overkill.
- stick to "use a JSON parser" and remove the final paragraph or say 
"Beware! The JSON data may not be secure even if you think it is"
- complete the final paragraph to say that it is not OK when the 
underlying application has more privileges than regular web applications.




[...]
>     3.4.10 Don't Send Cookie Information Unnecessarily
>     -----
>     The example in 3.4.10.2 could benefit from some more context (as in:
>     where is that "Set-Cookie" instruction supposed to go? Ah, it's a
>     header in the HTTP response, ok ok). I guess we should action
>     someone to review examples with a non-techie eye to ensure there can
>     be understand by as many people as possible.
> 
> 
> sounds good...  do you want to raise an action ?

Let's ask during today's call.


[...]

Francois.

Received on Tuesday, 5 May 2009 08:34:31 UTC