Paul Hoffman wrote:
The Security Considerations section is best viewed as warnings, not prescriptions. When you have too many prescriptions, the reader thinks that the prescription is sufficient to avert the warning.At 9:33 AM -0400 3/12/07, Elliotte Harold wrote:15.7 Code InjectionAtom Feed and Entry documents can contain almost any text or code you can imagine, including but not limited to SQL, PHP, HTML, CSS, XPath, and XQuery. Servers SHOULD escape all content received from a client after parsing and before storage as necessary to prevent its interpretation as code rather than as data.s/you can imagine// -- unneeded
agreed
s/SHOULD/may want to/ -- there are many reasons why a server would not want to escape the code, and they can't all be listed here
a lot of people seem to dislike the capital SHOULD, but I stilL think "may" is far too weak. If it's the RFC SHOULD that bothers people, I could go with something like "It is strongly recommedned that"
15.8 Cross Site ScriptingAPP content may contain JavaScript, PHP, malformed XML, invalid HTML, XInclude, entity references, and other possibly problematic text. Such text may or may not be double escaped. Servers that accept and publish content from untrusted, possibly anonymous sources--for example, in comments--SHOULD verify that client supplied content is safe for publication before posting it. In the case of HTML, experience suggests that verification be based on a white list of allowed content, rather than a black list of forbidden content.-1. Instead, keep the first sentence, nuke the rest, and add "This could lead to cross-site scripting, an attack that continues to evolve at the time of this writing."
Possibly. However I think it's critical to keep the second sentence too. The double escaping (type="html") is going to blow right through some filters.
I'm not sure I've described this particular problem well enough. In fact, I'm pretty sure I haven't. Probably we should call out type="html" as a particular problem here. Alternate language appreciated.
15.9 LengthAPP and Atom place few limitations on the length of content, extension element names, attribute values, and other constructs. Servers SHOULD be prepared to handle constructs of arbitrary length, if necessary by recognizing and rejecting input whose size exceeds what the server is prepared to handle.remove the last clause (", if necessary by ...") because it is impossible to implement.
Why? It's easy enough for the server to put in a prefilter that notes that a string is larger than the database schema is ready for and responds accordingly. I don't want to say how it does that because there are many different implementations, but it certainly should be possible in many of them.
-- Elliotte Rusty Harold elharo@xxxxxxxxxxxxxxx Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/