RE: [ISSUE-32] Implications of updates on protocol, regarding HTTP methods



> -----Original Message-----
> From: gearon@gmail.com [mailto:gearon@gmail.com] On Behalf Of Paul Gearon
> Sent: 29 July 2009 23:22
> To: Seaborne, Andy
> Cc: public-rdf-dawg@w3.org
> Subject: Re: [ISSUE-32] Implications of updates on protocol, regarding HTTP
> methods
> 
> On Wed, Jul 29, 2009 at 3:10 PM, Seaborne, Andy<andy.seaborne@hp.com> wrote:
> >
...


> >>
> >> Options for modifying the existing protocol for SPARQL/Update:
> >>
> >> Option 1: Write an unrelated new protocol for the HTTP binding
> >> SPARQL/Update to operate on.
> >> This would appear to be duplicating some work, and still needs to
> >> address how modifying operations need to be called.
> >
> > It has the advantage that different security can be applied at the HTTP
> level to the
> > different endpoints.  It also can help avoid confusion resulting on the
> same endpoint
> > between update and query operations causing injection attacks on the query
> endpoint.
> 
> I was never thinking that a writable interface should share the same
> connection as a query interface. I see the query-only interface to be
> an extremely valuable part of the specification. Any attempt to update
> it to handle write operations after authorization is guaranteed to
> create security holes in some implementations (that's even presuming
> the protocol doesn't include such holes).
> 
> On the other hand, I though that it might be convenient to have
> querying capabilities on the writing endpoint.

Agreed.

> If you have access to
> to write, then you already have all the permission you need to do
> damage. Besides, since INSERT and DELETE can be described using a
> query (an effective CONSTRUCT), and these should be capable of
> subqueries, then you'll be capable of doing complex queries anyway,
> even if you're not returning the results.

Yes, the operation is doing query but that not the same as a query interface which includes result formatting.

...
> >> Option 2 appears to offer the least difficulty. Are other options
> available?
> >
> > Options 1 and 2 (different endpoint, same endpoint) are both possible if we
> ensure an
> > update can't look like a query.
> 
> While I do agree with this, I'm more of a mind that any kind of update
> can only occur on a writable endpoint. If that is the case, then there
> is no reason to hide a write operation in a query, since writes are
> permitted anyway. Injecting a write into a query on such an endpoint
> would then be safe, though useless.

"No reason" seems to assume the client is not a malicious attacked :-)  Or buggy program.

I think it is useful that there are two "languages", not one language that includes everything.  That way, just parsing will throw errors if a query is expected and an update is sent.

It may be one grammar definition and two entry points - that's still two languages (sets of strings accepted).

> 
> > Given that POSTing a query is still "query=" in the body,
> > it's possible to do that.  But I think we should decide one of the other.
> 
> Well, if I were to indulge in wishful thinking, then I'd really like
> to reserve POST for writing and GET for reading (meaning that a
> read-only endpoint need only respond to GET), but I know that we can't
> rewrite the original protocol. I also know that POST was defined this
> way for compatibility with web forms, which is a valid use case. So
> now back to reality...
> 
> Given the existing protocol, I'd like to see GET be for queries alone,
> and POST accept parameters of query= and update= (or some similar
> name). On a read-only endpoint a POSTed parameter other than query=
> will return a 403. I believe this is option 2 since it is extending
> the read-only protocol to do read-write.

Looks good.  The SPARQL Protocol 1.0 only specifies returns 200, 400 and 500 (a design I argued against) but one can argue that if it's "request=" then it isn't a SPARQL protocol 1.0 request so the protocol spec does not apply.

   <fault ref="tns:MalformedQuery" whttp:code="400"/>
   <fault ref="tns:QueryRequestRefused" whttp:code="500"/>

 Andy

> 
> Regards,
> Paul

Received on Monday, 3 August 2009 07:55:47 UTC