I need to do some checking on a validation control but I am not sure what type of text ASP.NET will think is a security issue. Can someone give me some things to try? I tried various HTML tags and it seemed to accept them fine. This is a multiline rich textbox used for saving a field of text to the database. The code for saving is inside of an If Me.IsValid with no ELSE specified, but after the save function is called it proceeds to display a 'saved' message and redirect the page. Some users have been losing work so I think the problem is that Me.IsValid is false so the save function is called but does nothing... Anyways what can I try to invalidate this with? Note I did not write the code for this I am just troubleshooting it.
It sounds like you are confusing Validator controls with ValidateRequest, an internal mechanism of ASP.Net for sanitizing requests.
Validator validation is entirely dependant on your validators. Are you using a RequiredFieldValidator? Then the invalid inputs are simply blank textboxes. Is it a RegularExpressionValidator? Then you need to enter something that doesn't match the regular expression. CustomValidator? Then you need to check the validation logic.
It sounds to me more like you're worried about the input being sanitized for running database queries with. The first thing to check is that in your Page directive, "ValidateRequest" isn't being set to "false". If it is, that would explain why HTML is being allowed through.
You should also check out the following:
How to: Protect Against Script Exploits in a Web Application by Applying HTML Encoding to Strings
Validating User Input in ASP.NET Web Pages
Then, if you'd like to try a database injection attack, just google for a basic SQL Injection tutorial.
javascript:alert('rrrrrooooaaaarrrrr');
Is a good start.
Try some ASCII Codes for non breaking spaces, carriage return, etc.
Since you're saving to a database, try some sql injection as well.
Related
I was recently discussing this with someone, and I wasn't sure if this is an issue or not.
We are creating an ASP.NET website and if the user performs an action on a page we might create a database query using the Text values on controls that we have previously populated.
Could a user do something malicious like modify the text of a label control in their browser, then hit the update button and when we pull that label's .Text we end up inserting that value into the database?
It's easily done via firebug, for example, yes. Make sure you sanitize/validate any input coming in to prevent SQL injection or any other malicious intent.
Have a read of this MSDN article for more help.
I got a simple Site with a textbox where the user can enter some stuff. That Text is analysed and fancy stuff is done with it (like counting the words, displaying the text in another textbox)
No Database-Connection exists. No data is saved permanently
Do I still have to worry about code injection?
Can something harmful be done?
I agree with #nmat and want to add here that If you want to do check against the security, the only thing you need to consider is cross site scripting due to weird inputs in textbox. You can use Anti-cross site scripting library for validation. Same site is also having details regarding what I just said.
Depending on how you implement the application behaviour, plenty of things could go wrong. You don't have to worry about SQL injection because you don't have a database, but you may have problems if you aren't careful with the submitted data.
Add ASP validators to the TextBox to ensure that the user only submits data that you expect to receive. Ex: add a maximum length, a regex or other custom validation. ASP validators work both on the client side and on the server side so this should be enough protection in this case.
I need to localize an asp.net webapp with lots of pages.
So far what i'm doing is replace all text with literals where needed and i'm adding <%$ Resources: restype, reskey %> tags wherever needed. All the strings come from my database.
The problem is putting all the text in the database it's just a huge time spender.
I really don't want to be putting all the text in the database manually because everytime i finish a new page i have to go over the same excercise again.
So i came up with an idea:
What if i extended the localization resource handler with a default value like this (pseude code):
<asp:literal runat="server" Text='<%$ Resources: restype, reskey, 'This was the hard coded text' %>' />
When the page was first loaded the string resource wouldnt be in the database, but having the default text i can add it with the known resource type and key to my database. I could prefix the default values with a question mark for example. This allows me to check my table with strings and everywhere i see a text with a question mark i know it needs translating.
This way i only have to add resource tags to my markup and i avoid inserting all the text in my database. I just have to make sure to load every page once, which i can do locally in debug and then send the non-translated labels to a translator.
Please advise on this approach.
What we do here where I work is to declare string resources using special helper class. When the application is run, new string resources defined in code are auto-inserted into the database with their default value. The application works without any preparation steps. Later you can change the strings.
But yes, it requires some wrapper code to write.
Sounds like a nice idea, especially if you can't go along with the standard resource files mechanism which is automatically generated by VS.
Rick Strahl has written a solution for localizing ASP.net webapps to the DB. He's written some kind of Ajax UI which would even allow your users to translate the Webapp. The source code is also open, so you may take a look at it when developing your own solution.
Here's the link: http://www.west-wind.com/WestWindWebToolkit/
I've seen plenty of Cross-Site Scripting attack prevention suggestions, but I'm not asking about Form Input validation. How would I prevent something like this:
javascript:(function(i,j){with(document){for(i=0;i<forms.length;++i){with(forms[i]){for(j=0;j<elements.length;++j){elements[j].disabled=false}}}}})()
from being inserted into the URL? This code would enable all form elements on a page if added to a URL. So if you disabled certain buttons based due to permissions or something then all those buttons would become enabled.
Should I just be parsing the URL and check for the Javascript keyword?
No. You can't, anyway, as it doesn't get sent to the server.
That is just JavaScript executed locally by the user themselves. It should mean nothing to you. The security of your system should never rely on client-side javascript, all your authentication, and so on, should be done server-side.
The key is to not worry much about it client-side. Server-side is where you have to be bullet-proof. Do not assume, for example, that just because you named your form inputs the same as your database column names, that you can just loop through Request.Form and persist all the data you get. You should validate that you only process the inputs you are expecting, and validate them for data type and range, as well as considering the user's permissions to alter a given field.
That way, the user can send whatever they want, you will only process and accept valid data server-side.
If ASP.NET Request Validation is enabled for a site, do you still need to HtmlEncode and HtmlDecode string information to and from simple forms (e.g. ASP Textboxes)?
If ASP.NET Request Validation is enabled for a site, do you still need to HtmlEncode
ASP.NET Request Validation is a hack to try to work around stupid authors' broken programs. Don't write broken programs.
Any text string you write into an HTML page must be HTML-encoded; this is a matter of correctness, not just security (which is a subset of correctness). Even if Request Validation could magically remove any possible XSS attack (and that is so nothing like the case), failing to HtmlEncode text output would still leave you open to producing malformed output, mangling your data. Say I was making a forum post talking about some variables a, b and c and wanted to say:
a<b b>c b>a
If that was echoed to the HTML source unencoded, I'd get:
ac b>a
and maybe the rest of the page would be bold too. Whoops!
Request Validation is bogus and shouldn't be relied upon. Being on by default and “recommended for all production environments” is sad and makes me seriously doubt the sanity of the ASP.NET team.
If you have written your program correctly, you don't need it and it will just get in your way. (For example, if SO used it, I wouldn't be able to make this post that mentions the <script> tag.) If you haven't written your program correctly, Request Validation isn't going to fix your security holes, it's just going to make them a bit more obscure.
and HtmlDecode string information
You don't usually HtmlDecode anything in a web app. You encode to push content out into HTML, but when content comes back in from a submitted form it is as plain text, not HTML-encoded.
to and from simple forms (e.g. ASP Textboxes)?
Textboxes should be fine; setting their .Text does do any necessary encoding, making the exact string you had appear in the textbox. But. Some things that look like they should be HTML-encoding automatically actually don't. For example:
myTextBox.Text= "a<b b>c"; // Fine!
myLabel.Text= "a<b b>c"; // Broken!
Oh dear. Text does not always mean Text. Sometimes, it actually means HTML. Thank you Microsoft, way to muddy the waters of a topic too many people already find hard to understand.
There's no danger from text in ASP.NET text boxes, whether Request Validation is on or off. The text box control automatically encodes data when displayed in the text box.
When outputting data that originated from the user in other places, it is important to HTML (or JavaScript) encode that data. ASP.NET's Request Validation provides only a minimum level of protection. It is not impenetrable, or even close to it. It is only designed to protect against the most simple attacks.
You still have to encode things as you output them on other parts of your site.
Edit
What I mean by other places, is that if the user enters the data into a text box, using the ASP.NET Text Box control is safe because the control automatically encodes the output so it will render safely.
Say, for example, you're working with StackOverflow's user info page. When a user chooses their username they could choose to input something that may be malicious when output in another part of your site. For example my StackOverflow login name is displayed at the top of every page for me, and is also listed on the "Users" page.
On the Users page, AJAX is used to load users. When JavaScript goes to evaluate the user name, it is not bound by the same encoding rules as HTML tags, so I could type something into the user name text box that could cause some breaking behavior when it is output in the User list.
StackOverflow obviously encodes user data correctly when sent to the client, so they're safe. Before sending my user name off to the client, they (presumably) have some JavaScript encoding routine that makes sure that my user name can't become malicious when executed in JavaScript code.
You could also have problems if using it in a non-ASP.NET input control. Input tags use attributes to define content, so you can easily enter text that would get past the Request Validation check but could allow the user to add a malicious "mouseover" attribute.