- Feature Articles
- CodeSOD
-
Error'd
- Most Recent Articles
- Stop Poking Me!
- Operation Erred Successfully
- A Dark Turn
- Nothing Doing
- Home By Another Way
- Coast Star
- Forsooth
- Epic
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
++adaptability;
++extensibility;
security -= Universe.Atoms.Count;
Admin
Hmm,
I wonder what appending ";DROP TABLE [user]" would do.
Admin
This is even worse than storing raw sql in a cookie, as shown here a few weeks ago.
Somebody shoot me.
Admin
Might I suggest BugZilla?
Admin
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.
Admin
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.
Admin
We use Seapine's TestTrack Pro. It's incredibly easy to use and can be customized with the best of them.
Admin
Not for the rest of us...
Admin
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.
Admin
I think you better stick to acting ....
Admin
Uh, bs. They require you to buy a SDK just to automate the fscking thing
Admin
Admin
How do you think ad-hoc query interfaces work? I've written one. I suggest you stick to /.
Admin
Stored Procedures anyone??? Awww, come on... SQL injection it is then!! [:P]
Admin
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.
Admin
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.
Admin
That SQL string bears the odor of an MS Access backend.
Bonus Points!
Admin
hehe... lol... roflmao..... my colon hurts [:$]
Admin
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.
Admin
I was mostly responding to
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)
Admin
Here:
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.
Admin
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 :)
Admin
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.
Admin
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.
Admin
No, I think you've clearly established a truth value for that statement.
Admin
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!
Admin
With any luck, it will throw a YouReallyShouldntDoThatException.
Admin
Are you just trolling or are you really serious?
Admin
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.
Admin
On the "up" side, it should be easy to figure out the URL that provides the "search for tickets" functionality he's looking for . . .
Admin
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>
Admin
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.
Admin
When in doubt, hit the troll button. I know I did :)
And about the WTF, at least the password isn't in the URL :-/
Admin
Not a ImSorryDaveImAfraidICantDoThatException?
Admin
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.
Admin
appended to http://www.cluefire.net/
ok
dpm
Admin
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.
Admin
Sure.
SELECT credit_card_no, credit_card_expires FROM customers;
No harm done.
Admin
No - It's a stinking unusable POS.
Admin
Beat me to it! Darn.
Admin
You're right of course. However, I was simply referring to harm being done to the physical data on the database.
Admin
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.
Admin
Did you even read what you quoted?
Admin
Which is why you only give access to certain tables/fields.
Admin
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.
Admin
I thought you were (trolling)
Admin
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.
Admin
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.
Admin
For the sake of discussion, I'll play the Devil's Advocate.
Assuming appropriate database security:
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
Admin
Assuming proper DB security (GRANT SELECT ON MY_TABLE TO END_USER):
If your program happens to be called SQL*Plus, you damn well better expose the SQL to the user.
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.