Comments on: member variable values in the querystring == security risk? http://www.lazycoder.com/weblog/2007/10/08/member-variable-values-in-the-querystring-security-risk/ Wed, 08 Sep 2010 09:21:44 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Jason Haley http://www.lazycoder.com/weblog/2007/10/08/member-variable-values-in-the-querystring-security-risk/comment-page-1/#comment-95584 Jason Haley Sat, 20 Oct 2007 15:41:46 +0000 http://www.lazycoder.com/weblog/index.php/archives/2007/10/08/member-variable-values-in-the-querystring-security-risk/#comment-95584 <strong>Interesting Finds: October 20, 2007...</strong> ... Interesting Finds: October 20, 2007…

…

]]> By: More on querystring security | Lazycoder http://www.lazycoder.com/weblog/2007/10/08/member-variable-values-in-the-querystring-security-risk/comment-page-1/#comment-93284 More on querystring security | Lazycoder Wed, 10 Oct 2007 14:28:39 +0000 http://www.lazycoder.com/weblog/index.php/archives/2007/10/08/member-variable-values-in-the-querystring-security-risk/#comment-93284 [...] so the last post had some good responses. In that post I mainly looked at it the risk in putting params in the [...] [...] so the last post had some good responses. In that post I mainly looked at it the risk in putting params in the [...]

]]> By: Chad Myers http://www.lazycoder.com/weblog/2007/10/08/member-variable-values-in-the-querystring-security-risk/comment-page-1/#comment-93223 Chad Myers Wed, 10 Oct 2007 03:15:12 +0000 http://www.lazycoder.com/weblog/index.php/archives/2007/10/08/member-variable-values-in-the-querystring-security-risk/#comment-93223 Speaking of security, why are we still using predictable, incrementing integers was primary keys? Or rather, why are we exposing these to the Intarwebs? Shouldn't we have some sort of surrogate key that the app uses (something random, like a non-incrementing, random scatter GUID) that somehow gets mapped to the actual primary key ID in the database (which may be an int) Speaking of security, why are we still using predictable, incrementing integers was primary keys?

Or rather, why are we exposing these to the Intarwebs?

Shouldn’t we have some sort of surrogate key that the app uses (something random, like a non-incrementing, random scatter GUID) that somehow gets mapped to the actual primary key ID in the database (which may be an int)

]]> By: Haacked http://www.lazycoder.com/weblog/2007/10/08/member-variable-values-in-the-querystring-security-risk/comment-page-1/#comment-93051 Haacked Tue, 09 Oct 2007 05:41:45 +0000 http://www.lazycoder.com/weblog/index.php/archives/2007/10/08/member-variable-values-in-the-querystring-security-risk/#comment-93051 If an app allowed a user to delete something the user does not have the authority to delete via an URL like http://lazycoder.com/people/delete/1242, then the app is negligent towards security. It really doesn't make any difference if 1242 is in the URL or a hidden input. Hackers can find the "View Source" button. The URL is not the problem, it's allowing someone to delete something by changing the id when they don't have permission to. However, that seems incredibly rare. The real problem is allowing a delete (or any change) via a GET operation. It violates the semantics we'd expect from the web. But even that normally doesn't cause problems, because in most cases, authentication should prevent a web-crawler from accidentally deleting something it shouldn't. The problem we saw with the Google accelerator was that it was a client technology that ran with the user's browser stored credentials. Thus it could hit the those delete links with proper authentication. Again, this is resolved by making sure GET is idempotent and isn't allowed to change or delete data. If an app allowed a user to delete something the user does not have the authority to delete via an URL like http://lazycoder.com/people/delete/1242, then the app is negligent towards security.

It really doesn’t make any difference if 1242 is in the URL or a hidden input. Hackers can find the “View Source” button. The URL is not the problem, it’s allowing someone to delete something by changing the id when they don’t have permission to. However, that seems incredibly rare.

The real problem is allowing a delete (or any change) via a GET operation. It violates the semantics we’d expect from the web. But even that normally doesn’t cause problems, because in most cases, authentication should prevent a web-crawler from accidentally deleting something it shouldn’t.

The problem we saw with the Google accelerator was that it was a client technology that ran with the user’s browser stored credentials. Thus it could hit the those delete links with proper authentication.

Again, this is resolved by making sure GET is idempotent and isn’t allowed to change or delete data.

]]> By: Scott http://www.lazycoder.com/weblog/2007/10/08/member-variable-values-in-the-querystring-security-risk/comment-page-1/#comment-93048 Scott Tue, 09 Oct 2007 05:30:32 +0000 http://www.lazycoder.com/weblog/index.php/archives/2007/10/08/member-variable-values-in-the-querystring-security-risk/#comment-93048 I tried to remove any reference to a specific framework in this post because it's possible in any web application if you aren't careful/knowledgable. I tried to remove any reference to a specific framework in this post because it’s possible in any web application if you aren’t careful/knowledgable.

]]> By: What do you want out of a framework? | Lazycoder http://www.lazycoder.com/weblog/2007/10/08/member-variable-values-in-the-querystring-security-risk/comment-page-1/#comment-93012 What do you want out of a framework? | Lazycoder Mon, 08 Oct 2007 23:11:29 +0000 http://www.lazycoder.com/weblog/index.php/archives/2007/10/08/member-variable-values-in-the-querystring-security-risk/#comment-93012 [...] an interesting discussion with Blowmage (Mike Moore) over Twitter. I said that having the “param1/param2″ pattern in the ASP.NET MVC made me itchy from a security stan.... He replied. Eh, just don’t add them to the URL. The ASP.NET MVC assumes you know what you [...] [...] an interesting discussion with Blowmage (Mike Moore) over Twitter. I said that having the “param1/param2″ pattern in the ASP.NET MVC made me itchy from a security stan…. He replied. Eh, just don’t add them to the URL. The ASP.NET MVC assumes you know what you [...]

]]> By: Mike Moore http://www.lazycoder.com/weblog/2007/10/08/member-variable-values-in-the-querystring-security-risk/comment-page-1/#comment-93011 Mike Moore Mon, 08 Oct 2007 23:03:48 +0000 http://www.lazycoder.com/weblog/index.php/archives/2007/10/08/member-variable-values-in-the-querystring-security-risk/#comment-93011 To be clear, GET /people/delete/1242 is not a pretty URL. It *is* a dangerous URL. I would rather see one of the following from an authenticated user: POST /people/1242 (submit=delete) POST /people/ (submit=delete&person=1242) DELETE /people/1242 Of course, we all know a post-back from /RemoveUserFromDatabase.aspx?user_ID=1242 is the best way, right? ;) To be clear, GET /people/delete/1242 is not a pretty URL. It *is* a dangerous URL. I would rather see one of the following from an authenticated user:

POST /people/1242 (submit=delete)
POST /people/ (submit=delete&person=1242)
DELETE /people/1242

Of course, we all know a post-back from /RemoveUserFromDatabase.aspx?user_ID=1242 is the best way, right? ;)

]]> By: Mike Moore http://www.lazycoder.com/weblog/2007/10/08/member-variable-values-in-the-querystring-security-risk/comment-page-1/#comment-93004 Mike Moore Mon, 08 Oct 2007 22:35:31 +0000 http://www.lazycoder.com/weblog/index.php/archives/2007/10/08/member-variable-values-in-the-querystring-security-risk/#comment-93004 I was just about to ping you to post this so we can continue out twitter-fight as a blog-fight. :) But you seemed to have changed the conversation. I agree with everything you said here except for marking a value as "secure" or not. The "problem" you are describing is as old as the web itself. As long as we've been building web applications we've had these issues. I agree that all destructive actions should be POSTed to the server and the web app should have proper security in place. I may even agree that you might not want to use PK (primary keys) as your identifier; but only because you may want to grow beyond a RDBMS at some point. I honestly don't think that marking values "secure" is a feature that a web application framework should have. That said, if you want it and you can add that functionality with a plugin ala Rails or the extensibility model of the new ASP.NET MVC framework, then knock yourself out. But I would be very hesitant to use a framework that had that option by default though. I was just about to ping you to post this so we can continue out twitter-fight as a blog-fight. :) But you seemed to have changed the conversation. I agree with everything you said here except for marking a value as “secure” or not.

The “problem” you are describing is as old as the web itself. As long as we’ve been building web applications we’ve had these issues. I agree that all destructive actions should be POSTed to the server and the web app should have proper security in place. I may even agree that you might not want to use PK (primary keys) as your identifier; but only because you may want to grow beyond a RDBMS at some point.

I honestly don’t think that marking values “secure” is a feature that a web application framework should have. That said, if you want it and you can add that functionality with a plugin ala Rails or the extensibility model of the new ASP.NET MVC framework, then knock yourself out. But I would be very hesitant to use a framework that had that option by default though.

]]>