[cap-talk] solve CSRF by making references unforgeable, not unshareable

[John Carlson]

On Mar 25, 2009, at 9:41 AM, David-Sarah Hopwood wrote:

> John Carlson wrote:
>> zooko wrote:
>>> This insight leads us to propose the following aphorism: Solve CSRF
>>> attacks by making references unforgeable, not by making them
>>> unshareable.
>>
>> Wouldn't making SQL queries unforgeable solve the SQL injection  
>> problems?
>
> References are made unforgeable by making valid representations of  
> them
> either opaque or sparse (unguessable). Representations of SQL queries
> cannot be made opaque nor sparse.
>
> SQL injection (and injection attacks in general for any language) can
> be solved by ensuring that the structure of the query as parsed is the
> structure intended by the programmer. The easiest and simplest way to
> do this is for the query API to represent a query as an abstract  
> syntax
> tree, not a string.
>
> If you want a pithy aphorism:
> Strings are tricky. Don't rely on applications to say what they mean  
> as
> a string.

I am assuming that you would send the AST across the network  
(databases are on different machines than applications these days),  
thus it would be bytes.  I would use asymmetric encryption to make the  
AST SQL unforgeable.  I guess I would have to add a capability/ 
reference/swissnumber to the whole thing if the you wanted to stop  
repeatability.

I assumed that if one could make SAML unforgeable, one could make SQL  
unforgeable.

Actually, I could keep the SQL on the database server, and just pass a  
reference to it.  I realize this.
I think the moral is: keep all SQL in the database machine's disk or  
memory and use bind parameters.  That's okay with me...I want to work  
on user interfaces.

I am just thinking that the code I just wrote to create a .jpeg  
attachment name based on request parameters for download from the web  
may not be the best thing.

Sigh, I'm ready for a new web.  JavaScript here I come!

I'm ready for a dinner of words.

John