• (cs)

    ++adaptability;

    ++extensibility;


    security -= Universe.Atoms.Count;



  • Wowsers (unregistered) in reply to Ross Day

    Hmm,

    I wonder what appending ";DROP TABLE [user]" would do.

  • (cs)

    This is even worse than storing raw sql in a cookie, as shown here a few weeks ago.

    Somebody shoot me.

  • anonymous (unregistered)

    Might I suggest BugZilla?

  • (cs) in reply to rogthefrog
    rogthefrog:

    This is even worse than storing raw sql in a cookie, as shown here a few weeks ago.

    Somebody shoot me.



    You are correct. I thought it couldn't get any worse.

    Well, I suppose it could. User credentials could be embedded in plain text in the query string.

    And I could be on fire. That's always worse.
  • Sean Connery (unregistered)

    I don't think this is that bad. Its possible they used a specific user to do the query.

    SQL server and I'm sure other database servers allow you to restrict what users can do.

    But I doubt it.

  • (cs) in reply to anonymous

    We use Seapine's TestTrack Pro.  It's incredibly easy to use and can be customized with the best of them.

  • (cs) in reply to John Bigboote
    John Bigboote:

    And I could be on fire. That's always worse.


    Not for the rest of us...
  • (cs) in reply to John Bigboote
    John Bigboote:
    rogthefrog:

    This is even worse than storing raw sql in a cookie, as shown here a few weeks ago.

    Somebody shoot me.



    You are correct. I thought it couldn't get any worse.

    Well, I suppose it could. User credentials could be embedded in plain text in the query string.

    And I could be on fire. That's always worse.


    Funny that you mention user credentials in the query string.  When a piece of software was turned over to my current shop from the contractor, that was actually how the credentials were passed to the report server from the app server.  Plain, clear as day text in the query string.  Not even being on fire is that bad if you ask me.
  • (cs) in reply to Sean Connery

    Sean Connery:
    I don't think this is that bad. Its possible they used a specific user to do the query.

    SQL server and I'm sure other database servers allow you to restrict what users can do.

    But I doubt it.

    I think you better stick to acting ....

  • Sean Connery (unregistered) in reply to richleick

    Uh, bs. They require you to buy a SDK just to automate the fscking thing

  • Sean Connery (unregistered) in reply to richleick
    richleick:
    We use Seapine's TestTrack Pro.  It's incredibly easy to use and can be customized with the best of them.

    [image]
    Uh, bs. They require you to buy a SDK just to automate the fscking thing
    														</td></tr></tbody></table></td></tr></tbody>

  • Sean Connery (unregistered) in reply to Jeff S
    Jeff S:

    Sean Connery:
    I don't think this is that bad. Its possible they used a specific user to do the query.

    SQL server and I'm sure other database servers allow you to restrict what users can do.

    But I doubt it.

    I think you better stick to acting ....



    How do you think ad-hoc query interfaces work? I've written one. I suggest you stick to /.
  • (cs)

    Stored Procedures anyone???  Awww, come on...  SQL injection it is then!! [:P]

  • (cs) in reply to JThelen
    JThelen:

    Funny that you mention user credentials in the query string.  When a piece of software was turned over to my current shop from the contractor, that was actually how the credentials were passed to the report server from the app server.  Plain, clear as day text in the query string.  Not even being on fire is that bad if you ask me.


    I'll go you one worse.  At a company I used to work for, we archived sensitive financial data(statements, general ledgers, other reports).  We had a web interface that essentially just generated links to our third-party archival system.  These links contained username, password, and report specific details to locate the precise document that was archived.

    Now imagine taking off those report specific details from the URL.  That's right, you'd get an entire listing of our archival repository with a (fairly) easy-to-use interface that would allow you to look at any of the statements, reports, etc.

    Needless to say, I never did business with any of our financial institution clients.
  • (cs) in reply to Sean Connery
    Anonymous:
    Jeff S:

    Sean Connery:
    I don't think this is that bad. Its possible they used a specific user to do the query.

    SQL server and I'm sure other database servers allow you to restrict what users can do.

    But I doubt it.

    I think you better stick to acting ....



    How do you think ad-hoc query interfaces work? I've written one. I suggest you stick to /.

    To query a database passing the TSQL in a URL is not bad, just the user that it connects as must only have read access.  But when you pass TSQL through a URL to CRUD a database, that is bad.

  • (cs) in reply to Ytram

    That SQL string bears the odor of an MS Access backend.

    Bonus Points!

  • (cs) in reply to Ross Day

    Ross Day:
    ++adaptability;
    ++extensibility;

    security -= Universe.Atoms.Count;


    hehe... lol... roflmao..... my colon hurts [:$]

  • (cs) in reply to Sean Connery
    Anonymous:
    Jeff S:

    Sean Connery:
    I don't think this is that bad. Its possible they used a specific user to do the query.

    SQL server and I'm sure other database servers allow you to restrict what users can do.

    But I doubt it.

    I think you better stick to acting ....



    How do you think ad-hoc query interfaces work? I've written one. I suggest you stick to /.


    There's always a better way to store an ad-hoc query rather than displaying to the user via a URL query string.  Hell, even session variable opponents would probably favor session variables as opposed to URL encoded SQL.

    Sure, if the db user that was taking this raw SQL was limited to only read access, no harm could be done with URL manipulation.  However, you expose things you may not necessarily want the user to see, such as table names, column names, etc.  If a developer is stupid enough to dump raw SQL in the query string, then I'm sure they are probably stupid enough to allow SQL injection in any of the forms of the application.  If that's the case, then the user now also has access to precise table and column names.
  • Sean Connery (unregistered) in reply to cm5400
    cm5400:

    To query a database passing the TSQL in a URL is not bad, just the user that it connects as must only have read access.  But when you pass TSQL through a URL to CRUD a database, that is bad.



    I was mostly responding to


    That's right. SQL in the querystring.


    when I said its not that bad. But yes, CRUD in the query string by application design is bad, but by appropriate security, it does not make a difference (i.e. potentially damaging sql injection is avoided)
  • Sean Connery (unregistered) in reply to Ytram

    There's always a better way to store an ad-hoc query rather than displaying to the user via a URL query string.  Hell, even session variable opponents would probably favor session variables as opposed to URL encoded SQL.

    Sure, if the db user that was taking this raw SQL was limited to only read access, no harm could be done with URL manipulation.  However, you expose things you may not necessarily want the user to see, such as table names, column names, etc.  If a developer is stupid enough to dump raw SQL in the query string, then I'm sure they are probably stupid enough to allow SQL injection in any of the forms of the application.  If that's the case, then the user now also has access to precise table and column names.


    Here:
    Sean Connery:
    But I doubt it.


    I just wanted to say that there are valid situations and that non-dumbasses can use it appropriately.

    For example, in the ad-hoc query interface I designed, they could only see tables that were returned by stored procedures, not only that, the querying user could only _see_ those tables among other checks I put in.

    Whether or not I'm a dumbass is up for grabs.
  • Sean Connery (unregistered) in reply to Sean Connery

    There's always a better way to store an ad-hoc query rather than displaying to the user via a URL query string.  Hell, even session variable opponents would probably favor session variables as opposed to URL encoded SQL.


    Sure, if the db user that was taking this raw SQL was limited to only read access, no harm could be done with URL manipulation.  However, you expose things you may not necessarily want the user to see, such as table names, column names, etc.  If a developer is stupid enough to dump raw SQL in the query string, then I'm sure they are probably stupid enough to allow SQL injection in any of the forms of the application.  If that's the case, then the user now also has access to precise table and column names.



    By the way, the UI did not allow free text queries.

    Oh, also there was a translation phase where the query was converted to an intermediate representation that would catch the bad stuff. This intermediate representation was posted back to the server via the http POST method.

    But yeah, no SQL in the query string ;)

    To anyone reading this: I'm only explaining all this because I was really proud of myself, we got people to try to h4x it and it was unh4xable :)
  • (cs) in reply to Sean Connery
    Anonymous:

    There's always a better way to store an ad-hoc query rather than displaying to the user via a URL query string.  Hell, even session variable opponents would probably favor session variables as opposed to URL encoded SQL.

    Sure, if the db user that was taking this raw SQL was limited to only read access, no harm could be done with URL manipulation.  However, you expose things you may not necessarily want the user to see, such as table names, column names, etc.  If a developer is stupid enough to dump raw SQL in the query string, then I'm sure they are probably stupid enough to allow SQL injection in any of the forms of the application.  If that's the case, then the user now also has access to precise table and column names.


    Here:
    Sean Connery:
    But I doubt it.


    I just wanted to say that there are valid situations and that non-dumbasses can use it appropriately.

    For example, in the ad-hoc query interface I designed, they could only see tables that were returned by stored procedures, not only that, the querying user could only _see_ those tables among other checks I put in.

    Whether or not I'm a dumbass is up for grabs.


    Please describe a valid situation that would require a URL encoded SQL query as opposed to any other method for passing that query to another page.
  • (cs) in reply to Ytram
    Ytram:
    JThelen:

    Funny that you mention user credentials in the query string.  When a piece of software was turned over to my current shop from the contractor, that was actually how the credentials were passed to the report server from the app server.  Plain, clear as day text in the query string.  Not even being on fire is that bad if you ask me.


    I'll go you one worse.  At a company I used to work for, we archived sensitive financial data(statements, general ledgers, other reports).  We had a web interface that essentially just generated links to our third-party archival system.  These links contained username, password, and report specific details to locate the precise document that was archived.

    Now imagine taking off those report specific details from the URL.  That's right, you'd get an entire listing of our archival repository with a (fairly) easy-to-use interface that would allow you to look at any of the statements, reports, etc.

    Needless to say, I never did business with any of our financial institution clients.


    We had all that stuff in a plain text file on the server, along with database IP, SID, etc.  The only thing that remotely saves this is that the user/pwd that was passed didn't have sysdba access.  However, it was the schema owner.
  • (cs) in reply to Sean Connery

    Sean Connery:
    Whether or not I'm a dumbass is up for grabs.

    No, I think you've clearly established a truth value for that statement.

  • (cs)

    Awesome!  Coders who use the URL style of... http://magic/magictsd/Commonframe.asp?Ticket=1234 are limiting themself, I mean, look how much more flexible SQL in your url is!  Imagine being able to change the SA password right from the url, or perform all kinds of table truncating cleanup!

    In all seriousness, this one takes the cake for me, the best security hole I've seen on WTF ever!

  • (cs) in reply to Wowsers
    Anonymous:

    Hmm,

    I wonder what appending ";DROP TABLE [user]" would do.



    With any luck, it will throw a YouReallyShouldntDoThatException.
  • (cs) in reply to Sean Connery
    Anonymous:
    Jeff S:

    Sean Connery:
    I don't think this is that bad. Its possible they used a specific user to do the query.

    SQL server and I'm sure other database servers allow you to restrict what users can do.

    But I doubt it.

    I think you better stick to acting ....



    How do you think ad-hoc query interfaces work? I've written one. I suggest you stick to /.

    Are you just trolling or are you really serious? 

  • (cs) in reply to John Bigboote
    John Bigboote:
    Anonymous:

    Hmm,

    I wonder what appending ";DROP TABLE [user]" would do.



    With any luck, it will throw a YouReallyShouldntDoThatException.

    Exceptions are for losers who can't write bulletproof code. LOSERS, I TELLYA!

    This sql-in-get-string WTF makes me want to shoot out a random programming shop.

  • Ran (unregistered)

    On the "up" side, it should be easy to figure out the URL that provides the "search for tickets" functionality he's looking for . . .

  • chep (unregistered)

    It's ok - will secure it later by switching to https... [:D][:D][:D]

    <FONT style="BACKGROUND-COLOR: #d8d0c8">I like column names, especially [State:] and [InActive:] what the hell is ':' for??? </FONT>

  • (cs) in reply to chep
    Anonymous:

    <font style="background-color: rgb(216, 208, 200);">I like column names, especially [State:] and [InActive:] what the hell is ':' for??? </font>



    It's a holdover from Access.  If you design a query in Access like

    SELECT
        *
    FROM
        Orders
    WHERE
        State = [Please Enter State:]

    then running the query will cause Access to pop up a prompt with the field name as the prompt text.
  • (cs) in reply to Jeff S
    Jeff S:
    Anonymous:
    Jeff S:

    Sean Connery:
    I don't think this is that bad. Its possible they used a specific user to do the query.

    SQL server and I'm sure other database servers allow you to restrict what users can do.

    But I doubt it.

    I think you better stick to acting ....



    How do you think ad-hoc query interfaces work? I've written one. I suggest you stick to /.

    Are you just trolling or are you really serious?



    When in doubt, hit the troll button.  I know I did :)

    And about the WTF, at least the password isn't in the URL :-/
  • (cs) in reply to John Bigboote
    John Bigboote:
    Anonymous:

    Hmm,

    I wonder what appending ";DROP TABLE [user]" would do.



    With any luck, it will throw a YouReallyShouldntDoThatException.


    Not a ImSorryDaveImAfraidICantDoThatException?
  • (cs) in reply to Ytram

    Ytram:
    Anonymous:

    There's always a better way to store an ad-hoc query rather than displaying to the user via a URL query string.  Hell, even session variable opponents would probably favor session variables as opposed to URL encoded SQL.

    Sure, if the db user that was taking this raw SQL was limited to only read access, no harm could be done with URL manipulation.  However, you expose things you may not necessarily want the user to see, such as table names, column names, etc.  If a developer is stupid enough to dump raw SQL in the query string, then I'm sure they are probably stupid enough to allow SQL injection in any of the forms of the application.  If that's the case, then the user now also has access to precise table and column names.


    Here:
    Sean Connery:
    But I doubt it.


    I just wanted to say that there are valid situations and that non-dumbasses can use it appropriately.

    For example, in the ad-hoc query interface I designed, they could only see tables that were returned by stored procedures, not only that, the querying user could only _see_ those tables among other checks I put in.

    Whether or not I'm a dumbass is up for grabs.


    Please describe a valid situation that would require a URL encoded SQL query as opposed to any other method for passing that query to another page.

     

    I tend to agree here. When should someone put security matters in the backseat to something else? I'd really like to hear it. If Microsoft is any example, I understand they require a security plan, threat modeling, etc., prior to even starting to plan the project.

  • David P. Murphy (unregistered) in reply to Ross Day
    Ross Day:
    ++adaptability;

    ++extensibility;


    security -= Universe.Atoms.Count;






    appended to http://www.cluefire.net/

    ok
    dpm

  • Suomynona (unregistered) in reply to Sean Connery
    Anonymous:
    Jeff S:

    Sean Connery:
    I don't think this is that bad. Its possible they used a specific user to do the query.

    SQL server and I'm sure other database servers allow you to restrict what users can do.

    But I doubt it.

    I think you better stick to acting ....



    How do you think ad-hoc query interfaces work? I've written one. I suggest you stick to /.


    How do you think multiple levels of security work? Or do you think no one has ever found a hole in any security layer ever written?

    Maybe I shouldn't care what knuckleheads like you do to their own servers, but given that some of them might be responsible for the confidentiality of all our personal data, I'm all for the reintroduction of tar and feathers.

  • Suomynona (unregistered) in reply to Ytram
    Ytram:
    Sure, if the db user that was taking this raw SQL was limited to only read access, no harm could be done with URL manipulation.


    Sure.

    SELECT credit_card_no, credit_card_expires FROM customers;

    No harm done.

  • Richard (unregistered) in reply to anonymous

    Anonymous:
    Might I suggest BugZilla?

    No - It's a stinking unusable POS.

  • (cs) in reply to Suomynona
    Anonymous:
    Ytram:
    Sure, if the db user that was taking this raw SQL was limited to only read access, no harm could be done with URL manipulation.


    Sure.

    SELECT credit_card_no, credit_card_expires FROM customers;

    No harm done.



    Beat me to it!  Darn.
  • (cs) in reply to Suomynona
    Anonymous:
    Ytram:
    Sure, if the db user that was taking this raw SQL was limited to only read access, no harm could be done with URL manipulation.


    Sure.

    SELECT credit_card_no, credit_card_expires FROM customers;

    No harm done.



    You're right of course.  However, I was simply referring to harm being done to the physical data on the database.
  • (cs) in reply to Ytram

    NO HARM DONE????
    Haven't you been reading the news about stolen credit card info. If we, as programmers, don't do a better job of protecting sensitive user data, eventually someelse will.

    Ytram:
    Anonymous:
    Ytram:
    Sure, if the db user that was taking this raw SQL was limited to only read access, no harm could be done with URL manipulation.


    Sure.

    SELECT credit_card_no, credit_card_expires FROM customers;

    No harm done.



    You're right of course.  However, I was simply referring to harm being done to the physical data on the database.
  • (cs) in reply to Rick
    Rick:
    NO HARM DONE????
    Haven't you been reading the news about stolen credit card info. If we, as programmers, don't do a better job of protecting sensitive user data, eventually someelse will.

    Ytram:
    Anonymous:
    Ytram:
    Sure, if the db user that was taking this raw SQL was limited to only read access, no harm could be done with URL manipulation.


    Sure.

    SELECT credit_card_no, credit_card_expires FROM customers;

    No harm done.



    You're right of course.  However, I was simply referring to harm being done to the physical data on the database.


    Did you even read what you quoted?
  • Sean Connery (unregistered) in reply to Suomynona
    Anonymous:
    Ytram:
    Sure, if the db user that was taking this raw SQL was limited to only read access, no harm could be done with URL manipulation.


    Sure.

    SELECT credit_card_no, credit_card_expires FROM customers;

    No harm done.



    Which is why you only give access to certain tables/fields.
  • Sean Connery (unregistered) in reply to DelawareBoy
    DelawareBoy:

    I tend to agree here. When should someone put security matters in the backseat to something else? I'd really like to hear it. If Microsoft is any example, I understand they require a security plan, threat modeling, etc., prior to even starting to plan the project.



    The assumption is that sql query strings cannot be made safe. I contest this by saying that if you use appropriate database security, you can use query strings in a subset of applications.

    But that subset is probably limited to querying applications.
  • Sean Connery (unregistered) in reply to Jeff S
    Jeff S:
    Anonymous:
    Jeff S:

    Sean Connery:
    I don't think this is that bad. Its possible they used a specific user to do the query.

    SQL server and I'm sure other database servers allow you to restrict what users can do.

    But I doubt it.

    I think you better stick to acting ....



    How do you think ad-hoc query interfaces work? I've written one. I suggest you stick to /.

    Are you just trolling or are you really serious? 



    I thought you were (trolling)
  • (cs) in reply to Sean Connery
    Anonymous:
    DelawareBoy:

    I tend to agree here. When should someone put security matters in the backseat to something else? I'd really like to hear it. If Microsoft is any example, I understand they require a security plan, threat modeling, etc., prior to even starting to plan the project.



    The assumption is that sql query strings cannot be made safe. I contest this by saying that if you use appropriate database security, you can use query strings in a subset of applications.

    But that subset is probably limited to querying applications.

    I think is similar to what happens with Windows security vs Unix security. It's better to close everything and start opening things little by little, instead of giving everyone administrator priviledges. The same applies for SQL is better to create your own secure interface than living sql open and then trying to close it down.
  • (cs) in reply to Sean Connery
    Anonymous:
    DelawareBoy:

    I tend to agree here. When should someone put security matters in the backseat to something else? I'd really like to hear it. If Microsoft is any example, I understand they require a security plan, threat modeling, etc., prior to even starting to plan the project.



    The assumption is that sql query strings cannot be made safe. I contest this by saying that if you use appropriate database security, you can use query strings in a subset of applications.

    But that subset is probably limited to querying applications.


    There's a couple of problems with your stance:
    1.  If you're building SQL strings at the presentation layer, you're doing something wrong.
    2.  Exposing a SQL string to the user via an encoded URL is just plain a bad idea.  You do not want users to know what table and column names you have.
  • (cs) in reply to Ytram

    For the sake of discussion, I'll play the Devil's Advocate.

    Assuming appropriate database security:

    There's a couple of problems with your stance:
    1.  If you're building SQL strings at the presentation layer, you're doing something wrong.
    2.  Exposing a SQL string to the user via an encoded URL is just plain a bad idea.  You do not want users to know what table and column names you have.

    Why? 

    Why is it wrong to expose your SQL in the presentation layer?  What "rule of programming" is this breaking?

    and why don't you want your users to be able to see the sturcture of the underlying data?

    go

  • (cs) in reply to El Duderino

    Assuming proper DB security (GRANT SELECT ON MY_TABLE TO END_USER):

    El Duderino:
    Why is it wrong to expose your SQL in the presentation layer?  What "rule of programming" is this breaking?

    If your program happens to be called SQL*Plus, you damn well better expose the SQL to the user.
    El Duderino:
    and why don't you want your users to be able to see the sturcture of the underlying data?

    Well, maybe I want to be able to change things without having to tell the users about the changes.  Then again, maybe the users would like to be able to make their own queries without asking me to code up a query form first.  It depends.

Leave a comment on “Do You Believe In Magic?”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article