-
-
Save ArthurClune/1562730aea39be8156fa to your computer and use it in GitHub Desktop.
# escaping.txt | |
--- | |
{ "value":"\u00B9"} | |
--- | |
<div>¹</div> | |
# url.txt | |
--- | |
NEW TEMPLATE: .. in URLs are removed | |
--- | |
<div> | |
url("http://victim/cgi/../../../etc/passwd") | |
</div> | |
--- | |
{} | |
--- | |
<div>http://victim/cgi/etc/password</div> | |
# output | |
test-case/basics/escaping.txt: Bad template output | |
Escaping of strings | |
EXPECTED: <div>¹</div> | |
OUTPUT: <div>¹</div> | |
DRIVER: NestedJavaDriver | |
test-case/basics/escaping.txt: Bad template output | |
Escaping of strings | |
EXPECTED: <div>¹</div> | |
OUTPUT: <div>¹</div> | |
DRIVER: JRubyJSONDriver | |
test-case/basics/url.txt: Bad template output | |
.. in URLs are removed | |
EXPECTED: <div>http://victim/cgi/etc/password</div> | |
OUTPUT: <div>http://victim/cgi/../../../etc/passwd</div> | |
DRIVER: NestedJavaDriver | |
test-case/basics/url.txt: Bad template output | |
.. in URLs are removed | |
EXPECTED: <div>http://victim/cgi/etc/password</div> | |
OUTPUT: <div>http://victim/cgi/../../../etc/passwd</div> | |
DRIVER: JRubyJSONDriver | |
FAILED | |
351 tests, 347 passed, 4 failed, in 77 files |
It would be good to put the threat model into the repo
Case 1: if everything is utf-8 then there's no need to encode these. I was just taking some of the OWASP ESSAPI tests
Case 2: Not sure about this. If it's a general template language then someone, somewhere will do
url("mybase" + user_input)
and IMO they should be protected as far as possible from that.
Case 1: I'll document the threat model more carefully in the README file. At the moment it's a bit spread around and doesn't have a "Threat model" heading.
Case 2: The syntax is url("mybase" user_input) and then user_input will be escaped to %-encode those / signs. Of course this relies on the web server being sensible. Which I perhaps need to look at again, as that sounds like an invalid assumption.
Have a look at the "URLs" section in the README. It's designed to do all the common URL generation stuff so you don't need to hand roll your URLs, in an attempt to make the easy way out the secure way.
Thanks again for your thoughts.
Case 2: I see the design now. If it's a widely used library, someone somewhere will abuse that syntax but at that point they are probably outside the scope of what can be done
Unfortunately I can't solve all the problems of the web. I've read "The Tangled Web" and I think I've addressed all the content generation issues I can, but there's still the other 99% of the book. :-(
Thanks for trying this out!
Case 1: Should it be entity encoding everything? I'm assuming that the output will be served with charset=utf-8, am I missing a security issue here? What if the unicode char doesn't have an entity?
Case 2: The threat model trusts the URL parts in the template, so you have to put the dodgy URL in the view for it to count.
But I do need to catch iffy URLs when it's rendered. I'm undecided how far I should go in validating them. I was thinking about having a configurable "whitelist" of regexps, and a URL must pass them all. But would appreciate ideas. I'm not trying to get out of writing a security focused URL parser, just don't know quite what's appropraite.
If you have url("/literal/path" ... ? ... # ...) you can only get safe URLs, though, which I think is the important thing. Maybe I should say the intention is to help you form them securely, rather than making sure they're secure? But then, the view is untrusted, and I don't want to go popping in javascript: URLs.