Hi Kathleen, Personally - I'm not convinced, because the people who would benefit from that warning are almost certainly not going to be reading this document.
We're already getting a lot of pushback on the size of our document set; we've often resisted adding advice like this to keep it manageable for implementers N avoid it becoming a "kitchen sink" spec. With my chair hat on - what do others think? Sent from my iPhone > On 20 Nov 2013, at 3:57 am, "Moriarty, Kathleen" <kathleen.moria...@emc.com> > wrote: > > Hi Mark & Julian, > > I understand your concerns, but I think a *couple of sentences* could go a > long way in terms of awareness of these issues for developers and > implementers. This type of advice is on par with the current security > sections added for privacy concerns where you get close to the topic already. > If you read through Section 9.3 and consider predicable information (ID > numbers or other distinguishing information whether or not it is PII), it is > easy enough to plug in other values into a URI and possibly expose > information that should not have been accessible (with a bad configuration - > and they do exist). It would be good to make it clear that this is not a > good thing and can be one type of injection attack. > > You are also already covering full path disclosure in 9.1, which is a type of > injection attack. > > Julian had requested some text, here are a couple of proposed sentences. > In the last sentence of the first paragraph, add in 'predicable' to the list > of items at the end of the sentence. The I suggest adding text along the > following lines: > > Injection attacks, such as SQL and full path disclosure should be prevented > in URIs to avoid unintended access. The broader set of injection attacks is > out-of-scope for this document, however awareness is important for web > developers. > > OWASP lists injection attacks as the highest risk and defines the more broad > set of injection attacks as follows: > Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted > data is sent to an interpreter as part of a command or query. The attacker's > hostile data can trick the interpreter into executing unintended commands or > accessing data without proper authorization. (Link to OWASP top 10, it is > also provided as a PDF if that reference is better: > https://www.owasp.org/index.php/Top_10_2013-Top_10) > ---- > > This suggestion is meant to raises awareness and tie into the existing > descriptions that get close to this topic. > > Thank you, > Kathleen > > -----Original Message----- > From: Mark Nottingham [mailto:m...@mnot.net] > Sent: Monday, November 18, 2013 9:12 PM > To: Julian Reschke > Cc: HTTP Working Group; Moriarty, Kathleen > Subject: Re: #520, was: Fwd: Gen-Art review of > draft-ietf-httpbis-p2-semantics-24 with security considerations > > > On 19/11/2013, at 4:46 AM, Julian Reschke <julian.resc...@gmx.de> wrote: > >>> Section 9.3: You may want to include information that informs >>> developers and users of SQL injection attacks. Fields are still >>> included in some URIs that link you to pages directly that contain >>> personal information using consistent identifiers. It would be >>> helpful as this is still one of the biggest attack vectors. A quick >>> search on SQL injection URL will provide additional information for >>> inclusion in the write up. You mention GET-based forms in section >>> 9.3, but it doesn't mention SQL injection attacks and information in >>> the URIs. Since this is so prevalent still, I think it is important to call >>> out explicitly. >> >> Not convinced. From an HTTP point of view, URIs are just opaque identifiers. >> Also, there are many kinds of injection attacks. Should we list them all >> (XML, javascript...)? > > +1 - SQL doesn't have anything to do with HTTP, and even though it is used > often in conjunction with the protocol, it's an implementation-specific > choice. > > For example, I don't use any SQL on my Web site, and am very happy about that > :) > > Cheers, > > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
