105 reputation
10
bio website twitter.com/jweyrich
location Southern, Brazil
age 30
visits member for 4 years, 1 month
seen Oct 7 at 15:16

I have been working with C for 10+ years, Objective-C for ~3 years, and recently rediscovered C++. I have a public affair with statically typed languages and network protocols. Oh, I also sympathise with Python.

Did I help you somehow? If you think it's worth something and you're feeling generous, you may take a look at my wish list to see some books that would make me quite happy.


Jan
18
awarded  Nice Question
Oct
7
awarded  Popular Question
Sep
12
revised sslstrip vs. privoxy redirect rule on clients
corrected spelling
Sep
12
suggested approved edit on sslstrip vs. privoxy redirect rule on clients
Jan
11
awarded  Commentator
Jan
11
comment Access to a router's GUI
Even worst is that some routers allow configuring the gateway with a remote address. That way one could divert all the traffic and sniff everything from home.
Dec
29
awarded  Benefactor
Dec
29
comment Whitelisting DOM elements to defeat XSS
I put more thoughts on it, and I see this can be a bigger problem because it's NOT only about getting JS executed, it's also a possible layout change. The attacker could do something naughty like adding a link pointing to a malicious page and use CSS to overlay the entire page (like the XSS on Twitter). To deal with that, more parts of the browser would need to be touched, which is out of question. So we're back to stage zero: properly escape user data on server side.
Dec
29
awarded  Scholar
Dec
29
accepted Whitelisting DOM elements to defeat XSS
Dec
26
comment Whitelisting DOM elements to defeat XSS
I described the 1st point in previous comments, but I agree with the rest. Very good answer! +1
Dec
25
comment Whitelisting DOM elements to defeat XSS
If you guarantee that allowJavaScript is the first JavaScript to be executed, the evil title element won't cause any harm. It's a fairly simple requirement. JSON and HTML are completely different, so you can't have HTML elements in a JSON document. If you have, it's not a JSON document, and thus you should be able to invoke the proposed API.
Dec
25
comment Whitelisting DOM elements to defeat XSS
The developer can easily guarantee that allowJavaScript is the 1st function to be executed, and the browser can guarantee that it's called only once. Considering that, how would you introduce a foreign javascript into the body of the trusted page and get it executed (bypassing the protection)? If the client system is compromised and injects a JavaScript in the context of a loaded page, you can't call that XSS. Traffic manipulation isn't XSS too. Please, elaborate.
Dec
25
awarded  Promoter
Dec
25
comment Protecting an IIS web site hosted at home
Your question is too broad. IMO a good & comprehensive answer could easily fill some pages. Can you be more specific?
Dec
20
awarded  Student
Dec
20
comment Whitelisting DOM elements to defeat XSS
@AviD: that's a good point. I don't know if it's a tradeoff worth making. I really appreciate your input!
Dec
20
comment Whitelisting DOM elements to defeat XSS
@AviD: that's correct. One would normally whitelist only those elements that don't involve user supplied data. Otherwise, he still has to correctly escape AND validate the data. IMO it still decreases the attack surface by a very large magnitude.
Dec
20
revised Whitelisting DOM elements to defeat XSS
missing semicolon.
Dec
20
comment Whitelisting DOM elements to defeat XSS
I updated the question to clarify. You should be allowed to whitelist any element, and as many as you wish. The most obvious problem is the transition to the new model, but I risk to say it's unavoidable to any in-browser solution.