Subject: Re: [Gen-art] #520, was: Fwd: Gen-Art review of draft-ietf-httpbis-p2-semantics-24 with security considerations

From: "Moriarty, Kathleen" <[email-masked]>
Date: Wed, 20 Nov 2013 11:00:56 -0500

Hi Mark,

Then the same would be true for many of the other listed security/privacy considerations (privacy in URIs, mention of cookies within scope of privacy, etc.).  This is at the same level, but provides a pointer to look deeper.  The additional sentences round out the other considerations at the same level, pointing somewhere else to look for more information.

Thanks,
Kathleen

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]] 
Sent: Tuesday, November 19, 2013 5:38 PM
To: Moriarty, Kathleen
Cc: Julian Reschke; [email-masked]; [email-masked]; HTTP Working Group
Subject: Re: #520, was: Fwd: Gen-Art review of draft-ietf-httpbis-p2-semantics-24 with security considerations

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" <[email-masked]> 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:[email-masked]]
> 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 <[email-masked]> 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/
> 
> 
> 
>