Although this is something that only employees can use, I'd like to prevent the tampering anyway. I don't like insecure code, and this is hideously insecure.

Here's an example link:

<a href="#' + j.id + '" onclick="LoadThis(\'Test.aspx?id=' + obj.id + '\', \'post\', null, null);">Edit User #' + j.id + '.</a>

I sent this to the client side using jQuery:

    url: "Test.aspx/RemoveUsernameByID",
    type: "POST",
    data: 1,
    beforeSend: function (before) { /* do stuff */ },
    success: function (success) { /* do stuff */ },
    error: function (error) { /* do stuff */ }

...and make sure to use SqlCommand.Parameters.Add() to avoid bad stuff:

    public static void RemoveUsernameByID(int derp)
        string ConnectionString = "Data Source=herp;Initial Catalog=derp;Integrated Security=True";
        string QueryString = @"DELETE FROM [Herp] where [uid] = @derp";

        using (SqlConnection con = new SqlConnection(ConnectionString))
        using (SqlCommand cmd = new SqlCommand(QueryString, con)) 
            cmd.Parameters.Add("@derp", SqlDbType.Int).Value = derp;

Now, as you can see, this is hilariously bad. I am able to tamper with the id in data: 1, and send back any number to the web server to remove any user I want, by their ID. When using this kind of code, I can make myself an administrator, delete any user I want, gather information that I shouldn't be able to, etc.

I've thought about requesting and sending back a bunch of extra information, such as the user's first and last names, or a unique guid, but all someone has to do is sniff this information -- which I've just done! -- and collect it so they can keep doing whatever they want.

What should I do?


This seems more like a Direct Object Reference vulnerability than a SQL Injection vulnerability.

The proper way to secure this would be to check that the current session has permissions to perform the requested action on the server side. The details of how this would be down depends on how you have implemented authorization in your application, but reading the prevention section of the link I provided should be a good start.

  • This is an authorization issue and not an authentication issue.
    – Gumbo
    Feb 13 '15 at 18:47
  • Unfortunately, after extensive research, I am able to successfully exploit all of the suggested fixes. A properly authorized user can still perform all of these actions. I know they can, so "Why would they do that?" isn't a valid argument to me, because a disgruntled/malicious employee of Australian Taxation Office’s GST Start Up Assistance site used this against them in 2000.
    – heh
    Feb 13 '15 at 19:51
  • 1
    No one has made the argument, "Why would they do that" so I'm not sure why you mention it. If a "properly authorized" user can still perform unauthorized actions then they aren't properly authorized. I suspect that you aren't fully understanding how the authorization would work. How does authorization work on your current system? Feb 13 '15 at 19:59
  • Yeah, I know, but it's a typical argument, so I figured I'd cover it, and I probably shouldn't have. But perhaps you're right about me not fully understanding this. All users are administrators of the website, but they aren't allowed to do certain things (only the main site admin can, and that's done through SSMS). I do not want them to change the IDs through a tampering request. It wouldn't really hurt anything, but this is the symptom of a much bigger problem that I've yet to solve. While it's easy to exploit it, working around said exploit is what's giving me the trouble.
    – heh
    Feb 13 '15 at 20:02
  • The application logic would have to be updated. Direct object reference could be solved by storing the user id in session data upon successful login and this value could subsequently used instead of user supplied data. The application also seems to completely be missing authorization codes so this is likely present in most areas of the application
    – wireghoul
    Feb 13 '15 at 20:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.