Posted: 9/17/2012 11:52:03 AM EDT
|
Were you guys taught input validation in class? I am continuously blown away by the number of dot net developers that simply cannot get their head around input validation, standardized encoding, and output encoding. |
|
Quoted: Give an example, there are a couple ways to interpret each of those things. Lets say you have a zip code field. Just the standard 5 digits. You are expecting a numeric, 5 characters in length. Now, you can use client side javascript to restrict entry to other characters, but an attacker can easily bypass that by simply submitting the request outside of the browser. So here you are: Http://you.me/i.aspx?zip=12345 Inside the i.aspx file, what sort of validation do you typically do to ensure that you aren't submitting a % character into a strongly typed data field in the database? |
|
Quoted: I would say that applies to most programmers http://imgs.xkcd.com/comics/exploits_of_a_mom.png I find it is more pronounced in the .net community because many of those guys were trained as 'drag and drop' developers, and have a hard time coding outside the day to day field to database routine. No offense to anyone intended. There are some sharp .net guys out there. I'm just curious where the breakdown is. Training? Mindset? |
|
Offhand, I don't think I ever store zip codes as numbers, so it's sort of irrelevant.
For public forms, which I don't do often, I use parameterized queries for the whole shebang. So the only real risk is of some clod typing the wrong data into the wrong field. And that's usually caught on the javascript side of things. Oh, I do use numeric-input-only textboxes for certain input like that. Don't think I use it for zip codes, since some people like to give their 9 digit zip, and I don't really care either way. |
|
Quoted: Offhand, I don't think I ever store zip codes as numbers, so it's sort of irrelevant. For public forms, which I don't do often, I use parameterized queries for the whole shebang. So the only real risk is of some clod typing the wrong data into the wrong field. And that's usually caught on the javascript side of things. Oh, I do use numeric-input-only textboxes for certain input like that. Don't think I use it for zip codes, since some people like to give their 9 digit zip, and I don't really care either way. How do you block cross site scripting? What about buffer overflows? |
|
asp.net has a page-level option to block submission of form data which contains possible scripting and HTML data; it's "ValidateRequest" and defaults to true.
I occasionally have to disable it for certain business application pages which are specifically designed to permit HTML submission. And parameterized queries should halt buffer overflows. FTR, I'm a plain-text self-taught asp.net developer. And for bonus points, I write my stuff in an editor I wrote. I don't trust most of the drag-and-drop bullshit, but beneath the pakistani crap is an outstanding development architecture. |
|
Quoted: asp.net has a page-level option to block submission of form data which contains possible scripting and HTML data; it's "ValidateRequest" and defaults to true. I occasionally have to disable it for certain business application pages which are specifically designed to permit HTML submission. And parameterized queries should halt buffer overflows. FTR, I'm a plain-text self-taught asp.net developer. And for bonus points, I write my stuff in an editor I wrote. I don't trust most of the drag-and-drop bullshit, but beneath the pakistani crap is an outstanding development architecture. You are one of the few.  Unless the validation values are encrypted, they can be manufactured along side the forged values. I agree, the paramaterized queries will stop the buffer overflow on the database servers, but what about the app servers? |
|
Quoted:
Unless the validation values are encrypted, they can be manufactured along side the forged values. I'm not sure what you mean there. I agree, the paramaterized queries will stop the buffer overflow on the database servers, but what about the app servers? ASP.net simple data types are all managed with finite size, except string in which case it's a moot point. If someone's able to get in a buffer overflow attack against IIS, there's really not much I can do to prevent it from asp.net. (In terms of usability, input strings are usually limited via HTML or javascript where appropriate; not always appropriate) |
|
Quoted: Quoted: Unless the validation values are encrypted, they can be manufactured along side the forged values. I'm not sure what you mean there. I agree, the paramaterized queries will stop the buffer overflow on the database servers, but what about the app servers? ASP.net simple data types are all managed with finite size, except string in which case it's a moot point. If someone's able to get in a buffer overflow attack against IIS, there's really not much I can do to prevent it from asp.net. (In terms of usability, input strings are usually limited via HTML or javascript where appropriate; not always appropriate) http://planetofcoders.com/protect-view-state-tampering-passed-unencrypted-channel/ I guess, the point I am trying to make ab out input validation is that coding and reusing input validation routines is such a minimal amount of effort, why would you choose not to validation input at the application level? Defense in depth, in layers, etc. Also, there are a number of cases where the developers aren't able to use paramaterized queries, how do you handle those situations? |
|
My applications always have that viewstate guard enabled. I think it's a default. In a few cases I've had to work around it, such as when submitting a wholly dynamically generated form from a dynamically generated page which, obviously, has no viewstate.
I'm having trouble visualizing a scenario where there's a buffer overflow risk and I can't use parameterized queries to resolve it. |
|
Quoted: My applications always have that viewstate guard enabled. I think it's a default. In a few cases I've had to work around it, such as when submitting a wholly dynamically generated form from a dynamically generated page which, obviously, has no viewstate. I'm having trouble visualizing a scenario where there's a buffer overflow risk and I can't use parameterized queries to resolve it. That is just an example of the security issues which occur as the result of no validation. Things like XXE, File upload vulnerabilities, CSRF, Unvalidated redirects, etc. So I always get back to the old "why don't we" when it comes to input validation. Specifically at the application layer. |
|
I can't think of a time I've ever let users enter a URL, or directly control URL parameters.
It'd usually be more like "Enter the description of this page you want to add:", and then "Here's the URL for your new page: http://wherever/page.aspx?id=23". Setting aside the security concern, letting people control URL's is a recipe for disaster altogether. If you control for unique names, then you're giving them a tool to scan for existing page names by trying possible permutations. Even that aside, they might add improper characters or make the name too long, or too short, or who knows what. It's a usability issue before it's a security issue. |
|
Quoted: I can't think of a time I've ever let users enter a URL, or directly control URL parameters. It'd usually be more like "Enter the description of this page you want to add:", and then "Here's the URL for your new page: http://wherever/page.aspx?id=23". Setting aside the security concern, letting people control URL's is a recipe for disaster altogether. If you control for unique names, then you're giving them a tool to scan for existing page names by trying possible permutations. Even that aside, they might add improper characters or make the name too long, or too short, or who knows what. It's a usability issue before it's a security issue. Got it, so what happens when a user types in http://wherever/page.aspx?id=23' or http://wherever/page.aspx?id=a |
|
Well, it would get thrown into the parameterized query which would respond with a "wtf kind of number is 'a'?" error.
And if I don't care to check it there, it would get dropped into my SQL query which grabs the appropriate page while verifying the user's security access to that page. So, obviously, they won't get an arfcom forum screen for a forum they're banned from, even if they try entering the forum ID manually. (That second paragraph is where I see a lot of the indians and pakistanis choke; they really don't care about that concept, and they're convinced that the drag-and-drop interface magically handles it somehow if they do spare it a moment's thought.) |
|
Quoted: Well, it would get thrown into the parameterized query which would respond with a "wtf kind of number is 'a'?" error. And if I don't care to check it there, it would get dropped into my SQL query which grabs the appropriate page while verifying the user's security access to that page. So, obviously, they won't get an arfcom forum screen for a forum they're banned from, even if they try entering the forum ID manually. (That second paragraph is where I see a lot of the indians and pakistanis choke; they really don't care about that concept, and they're convinced that the drag-and-drop interface magically handles it somehow if they do spare it a moment's thought.) Wouldn't it make more sense for your application to handle that before passing it to the database? That is really where the crux of the issues exist that I find. The database should never receive un-sanitized user data, IMO. Now, user access rights is another set of issue all together. |
|
I don't really see why it needs to be handled in multiple places.
Let me put it this way; I can't think of a more reliable validation method than the one ado.net uses for parameterized queries. So I'm not sure what it would miss that I would catch. Bad data never even reaches MSSQL. I'm sorry, I can't shake the sense that you're slightly overreacting on this issue. I'm open to argument the other direction, as it would benefit me in my work. |
|
Quoted: I don't really see why it needs to be handled in multiple places. Let me put it this way; I can't think of a more reliable validation method than the one ado.net uses for parameterized queries. So I'm not sure what it would miss that I would catch. Bad data never even reaches MSSQL. So in this example: http://wherever/page.aspx?id=a The 'a' would never reach the database parser? |
|
Right, the parameterized query would assert the id's type as int/numeric.
Not even sure it'd reach ado.net, much less the database. Nonnumeric parameters get slightly more complex, but buffer overruns for strings are virtually a nonissue. And any SQL injection would become the string check. I guess there's theoretically a situation where cross site scripting on a certain high level page might be possible, but usually if you're allowing the framework for that, you're already dealing with max-authorization users anyway. |
|
Quoted: Let's try this. How would YOU validate that input? Specifically. Simple type and length check. If it isn't and int, between 1 and 3 in length, send back a page not found page or redirect to the home page. If you don't do this, and drop it into a query, you'll get a 500. |
|
Quoted: And how would do you validate a string strings? Sample code? It depends on what you are doing with the string. If it's a name, for example, use a whitelist. Using the ascii value of each character, verify that is an accepted value. a-z,A-Z,0-9,',- There is no reason to accept ~!@#$%^&*()+= etc in a field that is a username. You should also convert the resulting values to a common encoding, such as entity, before submitting it to a query. This completely kills all known vulnerabilities. |
Here is an example of hitting the app server, despite the use of paramaterized queriesServer Error in '/' Application.Maximum request length exceeded.Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: System.Web.HttpException: Maximum request length exceeded. Source Error:
Stack Trace:
|
|
Quoted: But it did error out, right? I'm not sure how that's a vulnerability. Server errors are typically precursors to vulnerabilities. Especially 500 errors. In this case, it is a precursor to a possible buffer overflow. I'm really less worried about the file size in this case, as the fact that the file type isn't being verified. Even file extensions aren't reliable. The moment the file header hit the server, the app code should have read it, and immediately stopped processing it. |
|
Quoted: nod, that's a legit one. Applications have to check uploaded file extensions before they do something with them, and some people don't bother. If you only check the extension, I can get a virus into your database or on your server file system. (depending on how you store image files) Just rename dd.exe to dd.jpg Then, I can use an OS commanding vulnerability, or direct call to download your entire database. |
|
Quoted: If you already have an OS commanding vulnerability, does it really matter whether there's a file up there? That is just one example, but yes it does. OS commanding vulnerabilities only affect the web server. Files in the DB server extend your reach further into the DMZ. |
|
Quoted: I'm not sure what the file would do that you can't do with the OS command hack, heh. OS commanding is a web/application server vulnerability. Storing a malicious file in a database reaches beyond that, into the database. Many applications share data tiers, and many data tiers are not locked down in the same manner as web or application tiers. ETA: Back to the point, though. File extension checking is not a sufficient defense against malicious file attacks, regardless of what tier they are targeting. |