Comment On Do You Believe In Magic?

++adaptability;


++extensibility;





security -= Universe.Atoms.Count;

Hmm,

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

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

Somebody shoot me.

Might I suggest BugZilla?

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.

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.

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

John Bigboote:

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

Not for the rest of us...

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.

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 ....

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

richleick:

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

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

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 /.

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

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.

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.

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

Bonus Points!

Ross Day:

++adaptability;
++extensibility;

security -= Universe.Atoms.Count;

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

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.

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)

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.

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 :)

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.

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.

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.

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!

Anonymous:

Hmm,

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

With any luck, it will throw a YouReallyShouldntDoThatException.

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? 

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.

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

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

I like column names, especially [State:] and [InActive:] what the hell is ':' for???

Anonymous:

I like column names, especially [State:] and [InActive:] what the hell is ':' for???

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.

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 :-/

John Bigboote:

Anonymous:

Hmm,

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

With any luck, it will throw a YouReallyShouldntDoThatException.

Not a ImSorryDaveImAfraidICantDoThatException?

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.

Ross Day:

++adaptability;


++extensibility;





security -= Universe.Atoms.Count;

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



ok

dpm

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.

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.

Anonymous:

Might I suggest BugZilla?

No - It's a stinking unusable POS.

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.

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.

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.

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?

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.

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.

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)

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.

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.

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

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.