The Daily WTF: Curious Perversions in Information Technology

chubertdev · 2013-07-18 Reply Admin

cellocgw:
I think the AC was sarcasmising there. However, in truth Microsoft DOES tell you whether the username is valid or not. They don't do it directly, but try this: attempt logging on with a valid username, and after a few (password)failures the system locks you out. Attempt logging on with an invalid username, and you can keep trying forever. This is almost as terrible a bug as the fact that the domain logs (quite possibly for systems other than Windows as well) record the username of every attempt. All you have to do is accidentally type your password into the Name field, then try again and login successfully, and your password and username are sitting prettily next to eachother in the log file, plaintext.

Yeah, in the systems I've worked on, we don't tell the user that it's locked through the interface, we send an email to the account on record.

The interface just always says, "Invalid username/password."

Pawprint · 2013-07-18 Reply Admin

Paul Neumann:
lucidfox:
;Select Case CommentBody
; Case "Frist"
;  Bad = True
;End Select
Damn, why does the server reject my commented-out VB code?
'Select Case CommentBody
'  Case "Frist":
'    Bad = True
'  Default:
'    Bad = Bad
'End Select
It's only because your 'commented' VB isn't syntactically valid.

[Notsureifserious.jpg]

VB doesn't put colons at the end of its Case statements.
In VB it's Case Else, not Default.

2013-07-18 Reply Admin

The HTTP status code should be 200 and the page should have an error message for the user.

When a user submits a form with a required field left blank, do you send back a 400? No, you send back a 200 with the same form again and that field highlighted in red.

chubertdev · 2013-07-18 Reply Admin

Pawprint:
[Notsureifserious.jpg]

VB doesn't put colons at the end of its Case statements.

In VB it's Case Else, not Default.

Neither of those points matter, since both statements are commented out, so it's fine to have them in VB. Just don't uncomment them...

chubertdev · 2013-07-18 Reply Admin

anonymous:
The HTTP status code should be 200 and the page should have an error message for the user.
When a user submits a form with a required field left blank, do you send back a 400? No, you send back a 200 with the same form again and that field highlighted in red.

I like this.

2013-07-18 Reply Admin

Simon:
rmarquet:
Anyone remember phpNuke?

What do you expect from something with the word 'nuke' in its name?

Of all the WTFy substrings in that name, you're concerned about 'nuke'?

What do you expect from something with the word 'hpnu' in its name?

2013-07-18 Reply Admin

jay:

Why tell the thief exactly how you caught him? This just gives him more information for his next try. If you catch him because you detected a SQL-injection attempt rather than, say, because his IP is on your watch-list, why tell him that?

Because when he tries the request again without the SQL injection, and it works, he'll figure out that's how you caught him anyway?

xaade · 2013-07-18 Reply Admin

Josh Ribakoff:
But it wasn't an attack.
And lots of websites do this. For example if I use the wrong password too much at my bank, they tell me so, and tell me to call my banker, they don't serve me a 404.

In the age of cellphones and email, they could just do what everyone else does and email/text you a message saying there was multiple login attempts and your account is blocked until you call in with this randomly generated code.

xaade · 2013-07-18 Reply Admin

Hmmmm:
Right or wrong, this is the way that SQL injection protection was done back then...

...and ...?

You have to have another point if you point is to disregard the point.

Or are you just trying to prove that the statement implies something other than what it implies.

xaade · 2013-07-18 Reply Admin

eViLegion:
Dave:
Protip: he was joking. Clearly.

Protip: 'Clearly' requires clarity.

What with a lot of people being incredibly stupid, it's entirely possible that an random unregistered person here could be that stupid.

In addition, typically, someone who's clearly joking manages to be funny.

Political correctness is incredibly stupid. I'm glad you cleared that up for everyone.

I'm a very pragmatic person.

If you get offended, that's your own emotion. So manage it by yourself. I don't expect to keep your friendship if your easily offended and I offend you. So, what other way can you "punish" me.

Addendum (2013-07-18 14:32): Just to clear that up.

I make it a point not to offend people, if it's reasonably sane. I have this personal belief as a backup to that. The point being, I don't feel morally obligated to keep you from being offended, but I'd like to try.

xaade · 2013-07-18 Reply Admin

jay:

When I worked for the government, I once filled out a form that included a box where they requested, "List all possible unforeseen problems that may prevent completion of this project on schedule". As I didn't foresee any unforeseen problems occurring, left it blank.

Seriously?

You know what that is right? That's the pregnancy trap. They want you to list any possible scenario you are considering that you haven't committed to (so basically anything that can put you on medical leave act). That's how most people approach having a child. "I can't foresee having a baby, but I want to, and we're trying."

And since they legally can't ask if you're trying to get pregnant, they do this.

Now, for private companies, I give them a pass on this, because it's a big cost to them to have half their staff on medical leave and be forced to leave the spots open for whenever those employees return, legally.

However, when the government employers do that, it's basically saying, "Yeah, I know we make it a point to protect women's 'equality' in the workplace, but we don't want to inhibit ourselves, just private sector businesses. We want to protect what we see as women's rights, but with someone else's money".

Which is basically bigotry in its most gruesome form.

Hmmmm · 2013-07-18 Reply Admin

xaade:
Hmmmm:
Right or wrong, this is the way that SQL injection protection was done back then...

...and ...?

You have to have another point if you point is to disregard the point.

Or are you just trying to prove that the statement implies something other than what it implies.

The point isn't to disregard the point, it is to disregard the correctness of the point...

2013-07-18 Reply Admin

anonymous:
The HTTP status code should be 200 and the page should have an error message for the user.
When a user submits a form with a required field left blank, do you send back a 400? No, you send back a 200 with the same form again and that field highlighted in red.

No, I don't agree that this is OK. RFC 2616:

10.2 Successful 2xx

   This class of status code indicates that the client's request was successfully received, understood, and accepted.

10.2.1 200 OK

   The request has succeeded. The information returned with the response is dependent on the method used in the request, for example:

   GET    an entity corresponding to the requested resource is sent in the response;

...

   POST   an entity describing or containing the result of the action;

By returning 200, you're stating to the client that "I did what you asked me to do. IF there's an entity in the response, that entity represents the results of what you asked me to do." If the request was not "successfully received, understood, and accepted" then 200 should not be returned.

2013-07-18 Reply Admin

403: "The request was a valid request, but the server is refusing to respond to it." is exactly right. There is nothing wrong with the request itself. However, the server is apparently vulnerable to SQL injections, and therefore refuses requests valid requests that resemble SQL injections.

HTTPbis (currently progressing through the IETF) says:

The 403 (Forbidden) status code indicates that the server understood the request but refuses to authorize it.

i.e. 403 is specifically for authorization related errors.

422 is a WebDAV extension and not part of RFC 2616.

This thread (very strongly) suggests otherwise - http://tech.groups.yahoo.com/group/rest-discuss/message/18542.

Note that Julian Reschke is one of the editors of HTTPbis. If he says 422 is the right code to use here, you should believe him.

In fact on the basis of the advice I've seen from him, I'm very happy to admit that my original posting (suggesting only 400 or 404) was incorrect and update my own REST code accordingly. 422 really is the correct response.

RichardD1 · 2013-07-18 Reply Admin

Sanitizing strings is a piss-poor way to prevent SQL Injection.

The only correct approach: http://bobby-tables.com/

2013-07-18 Reply Admin

Bullhonkey:
anonymous:
The HTTP status code should be 200 and the page should have an error message for the user.
When a user submits a form with a required field left blank, do you send back a 400? No, you send back a 200 with the same form again and that field highlighted in red.

No, I don't agree that this is OK. RFC 2616:
10.2 Successful 2xx

   This class of status code indicates that the client's request was successfully received, understood, and accepted.

10.2.1 200 OK

   The request has succeeded. The information returned with the response is dependent on the method used in the request, for example:

   GET    an entity corresponding to the requested resource is sent in the response;

...

   POST   an entity describing or containing the result of the action;
By returning 200, you're stating to the client that "I did what you asked me to do. IF there's an entity in the response, that entity represents the results of what you asked me to do." If the request was not "successfully received, understood, and accepted" then 200 should not be returned.

I'm going to go ahead and continue to say that the "wrong" response is correct here. The user is the one who needs to know what went wrong. There is no need for the browser to know this. The browser's request was successfully received, understood, and accepted by the server, and the result was a human-readable error message meant for the user, not their browser.

Aside: I tried clicking "Submit" without entering the captcha, and the HTTP result was "200 OK", despite giving me the same form again with "* That's not it" instead of posting my comment. I see nothing wrong with this. This is correct behavior.

2013-07-18 Reply Admin

[quote user="anonymousI'm going to go ahead and continue to say that the "wrong" response is correct here. The user is the one who needs to know what went wrong. There is no need for the browser to know this. The browser's request was successfully received, understood, and accepted by the server, and the result was a human-readable error message meant for the user, not their browser.

Aside: I tried clicking "Submit" without entering the captcha, and the HTTP result was "200 OK", despite giving me the same form again with "* That's not it" instead of posting my comment. I see nothing wrong with this. This is correct behavior.[/quote]

I'm not seeing an argument here for why 200 is the "correct" choice. You say that a human-readable response is necessary for the user to take appropriate action, and that's a fair point; but returning 400, 403, 404, 500, or 999 doesn't preclude that. Both the 4xx and 5xx status code classes bear the following general statement: [RFC 2616]

"Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. User agents SHOULD display any included entity to the user."

If the user agent understands that the request was not successful, it can provide an additional nudge to the user to examine the response body for what went wrong.

And, of course, in systems where there isn't a human being available to analyze the response body, the HTTP status code is the only information readily available to decide whether the request was successful or not.

In the specific scenario of posting a comment, I have a hard time understanding how you justify calling a request "accepted" when the clear intent of the request is "here is a commend I would like to post" and the actual result of the operation was anything but "the comment was posted," actual observed behavior notwithstanding.

If I do a GET request for http://someserver/badpath, is someserver justified in sending a 200 status code with a response body indicating that badpath couldn't be found? After all, "there is no need for the browser to know this." By your justification, all status codes should be abolished and replaced with 200.

chubertdev · 2013-07-18 Reply Admin

Bullhonkey:
anonymous:
The HTTP status code should be 200 and the page should have an error message for the user.
When a user submits a form with a required field left blank, do you send back a 400? No, you send back a 200 with the same form again and that field highlighted in red.

No, I don't agree that this is OK. RFC 2616:
10.2 Successful 2xx

   This class of status code indicates that the client's request was successfully received, understood, and accepted.

10.2.1 200 OK

   The request has succeeded. The information returned with the response is dependent on the method used in the request, for example:

   GET    an entity corresponding to the requested resource is sent in the response;

...

   POST   an entity describing or containing the result of the action;
By returning 200, you're stating to the client that "I did what you asked me to do. IF there's an entity in the response, that entity represents the results of what you asked me to do." If the request was not "successfully received, understood, and accepted" then 200 should not be returned.

By that logic, an incorrect username/password should not be a 200.

2013-07-18 Reply Admin

Anon:
Guess you missed the initial lines that stripped spaces from the text?

That's my favorite part. First, replace %20 with space. Then replace + with space. Then remove spaces.

2013-07-18 Reply Admin

Kuba:
rmarquet:
Anyone remember phpNuke? It would look for SQL keywords like this - "union" was the one that I usually stumbled into - and if you tried to post a message with that word in it, it would throw you back to the site's main page, without explanation.
The classic Cargo Cult solution, if there ever was one. Why the fuck do people not get that SQL has syntax, and pasting random strings together doesn't guarantee that the splice points delineate elements of the AST (never mind the right elements)?! I tend to think that all those "I'm a self taught web developer, never read any CS books no no hurr durr." people are to blame. The PFY boy from Deep C is the perfect example of who I'm talking about.

To me the problem seems more that they don't think "what if someone decides to input quotes or whatever other character I'm using to delimit strings?"

People just don't seem to get the concept of escaping. Then again, natural languages don't have much support for things like nested quotes either.

See also: the countless comment forms that discard &, <, and >, presumably to stop HTML injection.

2013-07-18 Reply Admin

ubersoldat:
A 500 would be as wrong as a 404. In this case you HAVE to return a 400 because the problem is in the client request.

But the actual request isn't malformed. It's well-formed and the server understood it correctly, but it couldn't handle the data it was sent in the content body. That's an internal server error.

chubertdev · 2013-07-18 Reply Admin

BillR:
ubersoldat:
A 500 would be as wrong as a 404. In this case you HAVE to return a 400 because the problem is in the client request.

But the actual request isn't malformed. It's well-formed and the server understood it correctly, but it couldn't handle the data it was sent in the content body. That's an internal server error.

The server handled the content fine, so it's not even an error, it's a rejection of the content that was submitted. Hence why it should be a 200.

2013-07-18 Reply Admin

Perhaps someone like Matt Westwood could tell me why I have to enter my username at a secured site, then get redirected to a page that tells me I was logged out due to inactivity. I then have to log in again with the same damn username. Why? No idea. Talked to tech support and they said "security". Which pretty much means that they fucked up their logic in the home page.

2013-07-18 Reply Admin

chubertdev:
The server handled the content fine, so it's not even an error, it's a rejection of the content that was submitted. Hence why it should be a 200.

What universe do you live in where "rejection of the content that was submitted" is congruent with "the client's request was successfully received, understood, and accepted"? Just like "user agent" cannot be taken to mean "an interactive Mozilla-style web browser in front of which a human being is currently seated," "server" cannot be taken to mean "a general purpose Apache-style web browser." A web application that communicates over HTTP is a "server" for these purposes, regardless of whether that application is hosted behind what we traditionally think of as the "web server." In other words, if the request as provided does not make sense to the web application in charge of providing a response, then an error response is appropriate, regardless of whether the "bare" request was minimally understandable to a general purpose HTTP server acting as a gateway for the web application.

chubertdev · 2013-07-18 Reply Admin

Bullhonkey:
chubertdev:
The server handled the content fine, so it's not even an error, it's a rejection of the content that was submitted. Hence why it should be a 200.

What universe do you live in where "rejection of the content that was submitted" is congruent with "the client's request was successfully received, understood, and accepted"? Just like "user agent" cannot be taken to mean "an interactive Mozilla-style web browser in front of which a human being is currently seated," "server" cannot be taken to mean "a general purpose Apache-style web browser." A web application that communicates over HTTP is a "server" for these purposes, regardless of whether that application is hosted behind what we traditionally think of as the "web server." In other words, if the request as provided does not make sense to the web application in charge of providing a response, then an error response is appropriate, regardless of whether the "bare" request was minimally understandable to a general purpose HTTP server acting as a gateway for the web application.

Here's where you err. The request DOES make sense to the web application. So much in fact that there's a scenario developed precisely to handle the situation.

chubertdev · 2013-07-18 Reply Admin

In fact, why are we even talking about what status code this returns?

It should be a 200 with the message on the screen, "Your page was successfully updated because this CMS isn't a POS and doesn't try to defend against SQL injection with code that will end up on TheDailyWTF.com."

2013-07-18 Reply Admin

Simon:
LoztInSpace:
This is absolutely the correct way to deal with a security attack.
It's analogous to why you don't tell a user if it is their username or password was wrong (or whether the username even exists). It's enough information to let a hacker take the next step.

I love those login forms, where you are not told what went wrong, especially if it is some site I don't visit regularly. Did I use the wrong username? Or was it just a typo in my password? Oh, the website doesn't know either, now I try every combination of usernames and passwords I think I could have used on that site... and if the site is really bad, it completely clears the login form everytime and eventually locks my account after a few failed login attempts (which even allows for a nice DoS attack, but I think might be ok for a banking site, to be fair).

I know, you should try to reduce the amount of information you give to criminals, but I don't know if giving unclear error messages in login forms really helps that much. I'd guess a criminal could easily get a list of valid usernames in some other way on most sites (e.g. trying to send a message to a user or use a password reset form [oh, and if you don't tell me I entered a wrong username there, I really hate you...]).

Of course, I could have entered a valid username of someone else, so "user exists" does not always imply I did not enter the wrong username, so after a few failed attempts, the site could give me a hint that I might have entered the wrong username.

I like people like you. I set up websites that ask for username and password, and then store what you put. It never ceases to amaze me how many people will cycle through every password they ever use when they get rejected. Often they change usernames too in an attempt to log in, and you can get some pretty good idea on what passwords people might use for different things. (and if you ask for an email address instead of a username you can often find out what their password is to their actual email account - yes, it's amazing how many people think it's secure to sign up to "hackerz R us" with their primary email address and the same password they use for their email account.

2013-07-18 Reply Admin

Anonymous Croward:
LoztInSpace:
It's analogous to why you don't tell a user if it is their username or password was wrong (or whether the username even exists).
Bullshit. Microsoft does that (tell you whether your password or username was wrong) and I applaud them. Good to know there are decent companies that don't listen to "good security practices" like this one.

oh the trolls....

LoztInSpace · 2013-07-18 Reply Admin

Bill:
Kuba:
rmarquet:
Anyone remember phpNuke? It would look for SQL keywords like this - "union" was the one that I usually stumbled into - and if you tried to post a message with that word in it, it would throw you back to the site's main page, without explanation.
The classic Cargo Cult solution, if there ever was one. Why the fuck do people not get that SQL has syntax, and pasting random strings together doesn't guarantee that the splice points delineate elements of the AST (never mind the right elements)?! I tend to think that all those "I'm a self taught web developer, never read any CS books no no hurr durr." people are to blame. The PFY boy from Deep C is the perfect example of who I'm talking about.
To me the problem seems more that they don't think "what if someone decides to input quotes or whatever other character I'm using to delimit strings?"
People just don't seem to get the concept of escaping. Then again, natural languages don't have much support for things like nested quotes either.

See also: the countless comment forms that discard &, <, and >, presumably to stop HTML injection.

Exactly and it shits me to tears. So now what happens when some web developer discovers JSON? Now no : {, }, [ ] etc " as well?
Boss: Ok, we need a CSV output. Developer: Ok! No commas allowed in the input now!

How fucking hard is it?

Only accept input that makes sense for your domain irrespective of the technology 2a) When using a specific technology make sure you convert data to the appropriate encoding (SQL server = parameters, HTML = HTML encoding, XML=XML encoding, URL= URL encoding, CSV=CSV encoding, JSON=JSON encoding.) 2b) Do it at the last minute - don't encode it early on, store it in the database then wrestle with ad-hoc decodes when you find you use it before it needs to be encoded...sheesh!

2013-07-18 Reply Admin

ubersoldat:
Security by obscurity and a PITA to debug. Thanks but try again.

Obscurity is a useful form of security - it just shouldn't be the only kind. You shouldn't depend on hackers not having information, but that doesn't mean you should give them the info for free.

2013-07-18 Reply Admin

ZoomST:
Not again please: The error is in the Server side since the SQL injection protection code is utter crap (highlighting by me). The argument comes as: was this failure unexpected by the original coder (happy one), or expected (forced by management)? Then maybe we need a new 6xx range to express WTF-side errors.

Pretty much. I'd say there is no correct status code to be sending in this case, because the situation only arises because of incompetent coding. And regardless of how common that might be, that's not covered by the spec, because changes are the incompetent coder hasn't read the spec anyway...

2013-07-18 Reply Admin

LoztInSpace:
So now what happens when some web developer discovers JSON? Now no : {, }, [ ] etc " as well? Boss: Ok, we need a CSV output. Developer: Ok! No commas allowed in the input now!

No punctuation of any form allowed, and no correctly-spelled words either, in case they can inject something with them. Eh, who's going to notice that? 99% of online commentary will go straight past such a filter without problems... ;)

2013-07-18 Reply Admin

xaade:
jay:

When I worked for the government, I once filled out a form that included a box where they requested, "List all possible unforeseen problems that may prevent completion of this project on schedule". As I didn't foresee any unforeseen problems occurring, left it blank.

Seriously?

You know what that is right? That's the pregnancy trap. They want you to list any possible scenario you are considering that you haven't committed to (so basically anything that can put you on medical leave act). That's how most people approach having a child. "I can't foresee having a baby, but I want to, and we're trying."

And since they legally can't ask if you're trying to get pregnant, they do this.

Now, for private companies, I give them a pass on this, because it's a big cost to them to have half their staff on medical leave and be forced to leave the spots open for whenever those employees return, legally.

However, when the government employers do that, it's basically saying, "Yeah, I know we make it a point to protect women's 'equality' in the workplace, but we don't want to inhibit ourselves, just private sector businesses. We want to protect what we see as women's rights, but with someone else's money".

Which is basically bigotry in its most gruesome form.

right or wrong I think this is justified.

People seem to forget that the people hiring someone to do a job should have some sort of right that that job gets done - so if they need someone to work flat out for 12 months and there's a chance that person isn't available for part of those 12 months then they sort of need to know that....

2013-07-18 Reply Admin

[quote user="Bullhonkey"][quote user="anonymous]I'm going to go ahead and continue to say that the "wrong" response is correct here. The user is the one who needs to know what went wrong. There is no need for the browser to know this. The browser's request was successfully received, understood, and accepted by the server, and the result was a human-readable error message meant for the user, not their browser.

Aside: I tried clicking "Submit" without entering the captcha, and the HTTP result was "200 OK", despite giving me the same form again with "* That's not it" instead of posting my comment. I see nothing wrong with this. This is correct behavior.[/quote]

I'm not seeing an argument here for why 200 is the "correct" choice. You say that a human-readable response is necessary for the user to take appropriate action, and that's a fair point; but returning 400, 403, 404, 500, or 999 doesn't preclude that. Both the 4xx and 5xx status code classes bear the following general statement: [RFC 2616]

"Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. User agents SHOULD display any included entity to the user."

If the user agent understands that the request was not successful, it can provide an additional nudge to the user to examine the response body for what went wrong.

And, of course, in systems where there isn't a human being available to analyze the response body, the HTTP status code is the only information readily available to decide whether the request was successful or not.

In the specific scenario of posting a comment, I have a hard time understanding how you justify calling a request "accepted" when the clear intent of the request is "here is a commend I would like to post" and the actual result of the operation was anything but "the comment was posted," actual observed behavior notwithstanding.

If I do a GET request for http://someserver/badpath, is someserver justified in sending a 200 status code with a response body indicating that badpath couldn't be found? After all, "there is no need for the browser to know this." By your justification, all status codes should be abolished and replaced with 200.[/quote]Disclaimer: I don't work in network related stuff

I would have thought the return codes are protocol-specific. This means that a 200 would be returned when from a http perspective the message has been received and accepted. The issue here is in data beyond the HTTP request - the HTTP request is decipherable and acted on, and I tend to agree the correct return would be HTTP success (200) along with a message/page that explains the user what they tried to do beyond the HTTP stuff was no workie.

Of course, the line between HTTP, the internet, web apps etc has really been blurred in the last few lustra, but surely the codes were originally intended to be specific to the protocol, not to the page/app/whatever providing it. An address that points to something that doesn't exist (or is not allowed) is a problem. A user using a bodgey password might be a problem, but not in terms of HTTP (or at least not in this example).

2013-07-18 Reply Admin

fsa:
Bullhonkey:
anonymous:
I'm going to go ahead and continue to say that the "wrong" response is correct here. The user is the one who needs to know what went wrong. There is no need for the browser to know this. The browser's request was successfully received, understood, and accepted by the server, and the result was a human-readable error message meant for the user, not their browser.
Aside: I tried clicking "Submit" without entering the captcha, and the HTTP result was "200 OK", despite giving me the same form again with "* That's not it" instead of posting my comment. I see nothing wrong with this. This is correct behavior.

I'm not seeing an argument here for why 200 is the "correct" choice. You say that a human-readable response is necessary for the user to take appropriate action, and that's a fair point; but returning 400, 403, 404, 500, or 999 doesn't preclude that. Both the 4xx and 5xx status code classes bear the following general statement: [RFC 2616]

"Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. User agents SHOULD display any included entity to the user."

If the user agent understands that the request was not successful, it can provide an additional nudge to the user to examine the response body for what went wrong.

And, of course, in systems where there isn't a human being available to analyze the response body, the HTTP status code is the only information readily available to decide whether the request was successful or not.

In the specific scenario of posting a comment, I have a hard time understanding how you justify calling a request "accepted" when the clear intent of the request is "here is a commend I would like to post" and the actual result of the operation was anything but "the comment was posted," actual observed behavior notwithstanding.

If I do a GET request for http://someserver/badpath, is someserver justified in sending a 200 status code with a response body indicating that badpath couldn't be found? After all, "there is no need for the browser to know this." By your justification, all status codes should be abolished and replaced with 200.
Disclaimer: I don't work in network related stuff

I would have thought the return codes are protocol-specific. This means that a 200 would be returned when from a http perspective the message has been received and accepted. The issue here is in data beyond the HTTP request - the HTTP request is decipherable and acted on, and I tend to agree the correct return would be HTTP success (200) along with a message/page that explains the user what they tried to do beyond the HTTP stuff was no workie.

Of course, the line between HTTP, the internet, web apps etc has really been blurred in the last few lustra, but surely the codes were originally intended to be specific to the protocol, not to the page/app/whatever providing it. An address that points to something that doesn't exist (or is not allowed) is a problem. A user using a bodgey password might be a problem, but not in terms of HTTP (or at least not in this example).

2013-07-19 Reply Admin

Volker:
400 is a "Syntax error", thus I'd choose 422 (Unprocessable) according to RfC 4918, or maybe 403 (forbidden).

403 is reserved for authentication/user right assignment related error and disn't right to be used in this case.

2013-07-19 Reply Admin

Nick:
It will look for ';DECLARE' as well as '; DECLARE' because spaces ave already been stripped.
TRWTF is having to go to great lengths to protect against SQL injection anyway. Why not just use parameterised queries? Or does that mickey-mouse language not have them?

Somthing like ";BEGIN TRUNCATE TABLE [tablename] END" would have passed through.

Using text pattern to filter and declare "guarded against SQL injection" is plain bad.

2013-07-19 Reply Admin

VB-compiler rejects it too. "Compile error: Syntax error"

Use ' instead of ; for comments.

2013-07-19 Reply Admin

ZoomST:
Just passing by:
Check: http://www.iacr.org/archive/eurocrypt2002/23320530/cbc02_e02d.pdf
I am the only one that by reading the beginning of the 4th page reads O'rly instead of O(r|y) = 0?? HACKER - I'm hacking your server successfully with a Last Word Oracle attack! I't super-effective! ADMIN - O RLY???

Yes. It seems you are to only one reading it.

Matt Westwood · 2013-07-19 Reply Admin

Phuul:
Perhaps someone like Matt Westwood could tell me why I have to enter my username at a secured site, then get redirected to a page that tells me I was logged out due to inactivity. I then have to log in again with the same damn username. Why? No idea. Talked to tech support and they said "security". Which pretty much means that they fucked up their logic in the home page.

O dear, did I really write something that does this? Which website was this? Let me know and I'll see what I can do to fix it.

Matt Westwood · 2013-07-19 Reply Admin

hugh:
xaade:
jay:

When I worked for the government, I once filled out a form that included a box where they requested, "List all possible unforeseen problems that may prevent completion of this project on schedule". As I didn't foresee any unforeseen problems occurring, left it blank.

Seriously?

You know what that is right? That's the pregnancy trap. They want you to list any possible scenario you are considering that you haven't committed to (so basically anything that can put you on medical leave act). That's how most people approach having a child. "I can't foresee having a baby, but I want to, and we're trying."

And since they legally can't ask if you're trying to get pregnant, they do this.

Now, for private companies, I give them a pass on this, because it's a big cost to them to have half their staff on medical leave and be forced to leave the spots open for whenever those employees return, legally.

However, when the government employers do that, it's basically saying, "Yeah, I know we make it a point to protect women's 'equality' in the workplace, but we don't want to inhibit ourselves, just private sector businesses. We want to protect what we see as women's rights, but with someone else's money".

Which is basically bigotry in its most gruesome form.
right or wrong I think this is justified.

People seem to forget that the people hiring someone to do a job should have some sort of right that that job gets done - so if they need someone to work flat out for 12 months and there's a chance that person isn't available for part of those 12 months then they sort of need to know that....

If they need someone to work flat out for 12 months they need to make that very clear in the hiring process. Three months, yeah, 6 months maybe, but 12 months no way. I'd demand at least 2 weeks off during that time to take the family away for a while, and perhaps so we could visit the inlaws at xmas for a day or two.

tchize · 2013-07-19 Reply Admin

ubersoldat:
A 500 would be as wrong as a 404. In this case you HAVE to return a 400 because the problem is in the client request.

If all else fail, always resort to the HTTP 418 error code.

2013-07-19 Reply Admin

Sorry, but I was taught that you always return 404 whatever the real error because the bad guys can deduce too much from the valid error messages.

Hans Meine · 2013-07-19 Reply Admin

ubersoldat:
A 500 would be as wrong as a 404. In this case you HAVE to return a 400 because the problem is in the client request.

I disagree. The problem clearly is on the server side.

Coyne · 2013-07-19 Reply Admin

ubersoldat:
A 500 would be as wrong as a 404. In this case you HAVE to return a 400 because the problem is in the client request.

I think it would be much more pertinent, if confusing, and scary to that naughty user, to return a "405 Forbidden".

2013-07-19 Reply Admin

Alnitak:
HTTPbis (currently progressing through the IETF) says:
The 403 (Forbidden) status code indicates that the server understood the request but refuses to authorize it.
i.e. 403 is specifically for authorization related errors.
422 is a WebDAV extension and not part of RFC 2616.
This thread (very strongly) suggests otherwise - http://tech.groups.yahoo.com/group/rest-discuss/message/18542.
Note that Julian Reschke is one of the editors of HTTPbis. If he says 422 is the right code to use here, you should believe him.

You are wrong. 403 is completely unrelated to authorisation. 403 means you won't get that page, no matter what authorisation you supply. 401 is used for missing authorisation; it means you can try the same request again supplying additional authorisation, and it might succeed.

And I don't care what Reschke is the editor of; if what he says is in clear contradiction to the relevant RFC then he is wrong.

2013-07-19 Reply Admin

Cheong:
Volker:
400 is a "Syntax error", thus I'd choose 422 (Unprocessable) according to RfC 4918, or maybe 403 (forbidden).
403 is reserved for authentication/user right assignment related error and disn't right to be used in this case.

Nonsense. 403: "The request was a valid request, but the server is refusing to respond to it.[2] Unlike a 401 Unauthorized response, authenticating will make no difference.[2] On servers where authentication is required, this commonly means that the provided credentials were successfully authenticated but that the credentials still do not grant the client permission to access the resource (e.g. a recognized user attempting to access restricted content)."

You won't be allowed to access the data, no matter what authentication you provide.

2013-07-19 Reply Admin

You're right, 400 Bad Request

2013-07-19 Reply Admin

faoileag:
Anonymous Croward:
faoileag:
It is not ok to do so in a web environment, and Microsoft doesn't do it either. At least not when logging in at Office.com.
They do when logging into login.live.com, which is the login page for Microsoft accounts (Outlook, SkyDrive, etc.)
Hmmm, not when I try it (using the link you supplied). I get "The email address or password is incorrect. Please try again."

Well that's odd. Anyway here's a screenshot.

2013-07-19 Reply Admin

fsa:
Disclaimer: I don't work in network related stuff
I would have thought the return codes are protocol-specific. This means that a 200 would be returned when from a http perspective the message has been received and accepted. The issue here is in data beyond the HTTP request - the HTTP request is decipherable and acted on, and I tend to agree the correct return would be HTTP success (200) along with a message/page that explains the user what they tried to do beyond the HTTP stuff was no workie.

Of course, the line between HTTP, the internet, web apps etc has really been blurred in the last few lustra, but surely the codes were originally intended to be specific to the protocol, not to the page/app/whatever providing it. An address that points to something that doesn't exist (or is not allowed) is a problem. A user using a bodgey password might be a problem, but not in terms of HTTP (or at least not in this example).

"The request" does not extend only to a physical file on a disk. For example, imagine that we have a server at someserver, which has a web application that displays something--recipes, let's say. We'll make it a RESTful-like API, so if I want to view recipe 1204, I send this request:

http://someserver/recipes/view/1204

So clearly we have some sort of application on someserver that handles requests of this form, goes out to the database to find recipe #1204, and returns the result to the user agent. Now, what happens if recipe #1204 doesn't exist? By your argument, the HTTP status code should be 200 since the app that returns recipes itself was successfully found, even though the recipe we asked for wasn't. I think we can all agree 404 is the right response here, despite there being no "protocol" issues involved. Is there a substantive difference between the above form and a non-RESTful form like:

http://someserver/recipe.cgi?id=1204

Again, in this case, the recipe app is successfully found, but the recipe we're asking for was not. In this case, we can argue that the query string is "extra data" that the HTTP server doesn't know or care about, and so from a "protocol perspective," the request was successful, even though the human sitting in front of the screen can clearly tell it was not.

But let's go back to RFC 2616 and look at some definitions.

A "resource" is "A network data object or service that can be identified by a URI".

A URI can be relative and some other stuff; what we're interested in is what an "http URL" looks like:

http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

Furthermore, when we compare URLs to see if they're equal "a client SHOULD use a case-sensitive octet-by-octet comparison of the entire URIs" with some exceptions that aren't relevant here.

So we see here that the query string isn't extraneous information. A unique query string represents a unique resource. http://someserver/recipe.cgi?id=1204 SHOULD return a 404 result because the resource we are asking for was not found, even though recipe.cgi was.

Now recall that form data, when using the GET method, is directly adjoined to the form action URL as a query string, and you see that a GET-submitted form is functionally identical to the kind of request discussed above. The entire request, query string included, represents a unique resource, and if there is a problem accessing that resource (because it doesn't exist, can't be authorized, the request was incomplete or erroneously stated, etc), then an appropriate HTTP status code should be returned.

Furthermore, POST is no escape hatch: "The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database."

By this rule, unique POST body content represents a unique resource, in the same way that every file in a subdirectory is a unique resource, and in the same way that every GET query string is a unique resource. And again, any problems with processing that resource should be responded to with an appropriate HTTP status code.

In particular, it should be noted that the "server"--from HTTP's perspective--is "[a]n application program that accepts connections in order to service requests by sending back responses". I think there's a tendency to focus on the first part--IIS or Apache or nginx is accepting the connection, so it's "the server"--but this definition makes it clear that if your web application is "sending back responses" (and it wouldn't be much of a web app if it weren't) then that makes it the "server," or at least some substantial part of the server. The transaction, after all, is not complete until it is responded to in some way!

HTTP 1.1 is not a low-level protocol; it is a high-level protocol, and an application providing responses to requests is a part of that protocol. So, I agree with you when you say "a 200 would be returned when from a http perspective the message has been received and accepted." Where we differ is where the "http perspective" ends. I think my reading of RFC 2616 clearly includes the web application as playing a crucial role in the protocol itself.

SQL Injection Not Found

Leave a comment on “SQL Injection Not Found”