search

deuterium / comp4900project

2 stars 0 forks source link

Fix Script Injection on All Pages #52

Open lindsayfester opened 13 years ago

lindsayfester commented 13 years ago

Go here and add this code to your page:

http://pasteit.com/102

It will add a filter to every textbox on your page so the use can't type chars to inject scripts and won't get that dangerous request error page.

deuterium commented 13 years ago

So what does this do? does it just completely reject <>&#'s?

&#'s should be a valid input to our comment boxes at least.

On Sun, May 22, 2011 at 12:18 AM, LindsayFester < reply@reply.github.com>wrote:

Go here and add this code to your page:

http://pasteit.com/102

It will add a filter to every textbox on your page so the use can't inject scripts.

Reply to this email directly or view it on GitHub: https://github.com/deuterium/comp4900project/issues/52

lindsayfester commented 13 years ago

It's the best solution. I do have a JavaScript solution that warns the user when they type that character, but it didn't work in some browsers (I don't remember which one).

See: http://stackoverflow.com/questions/6084783/full-list-of-xss-triggers-for-validaterequest-in-asp-net

deuterium commented 13 years ago

I didn't say it wasn't a good solution, I'm saying that &'s and #'s could be valid inputs to a comment field, why should we just phase it out from use? injecting & is not going to hurt out page overall

lindsayfester commented 13 years ago

Okay so prevent the # sign, but still use the &? That could work. I wanted the user to be able to enter those, as they only trigger the error page when used together as &# . So choose one that they can use.

deuterium commented 13 years ago

So why can't they use a #?

lindsayfester commented 13 years ago

They can, just not with an & in front of it. We can change the filter to block neither and take a chance, or we can block only one of them (and I'm leaving it up to you to choose which one they can use).

The reason I'm not just showing the error page is because I tested it and if they try to go back to the form afterwards, they lose most data on the form. Not knowing why that's happening and possibly doing it again right afterwards would be very frustrating to the user.

deuterium commented 13 years ago

I think it's a horrible idea to restrict what they can type in a comments box as <>&#'s may all be valid in a scientific report.

Server.HtmlEncode/Decode would be the ideal solution

lindsayfester commented 13 years ago

It won't make it to the server! Asp.NET restricts it and turning it off would be a security risk. Read the stack overflow request. Even fields outside the validation group are still sent on a server/html request. I've tested it.

lindsayfester commented 13 years ago

Even if you let them type those chars, it will still trigger the error and they will lose everything they've just typed. I've put it in the documentation that these chars are not allowed.

deuterium commented 13 years ago

As per what I said, if you use Server.HtmlDecode/Encode and turn requestValidation to false

http://www.asp.net/learn/whitepapers/request-validation

deuterium commented 13 years ago

We will be using http://pasteit.com/102 due to the fact that a complete rewrite would basically be needed for Server.HtmlEncode/Decode

lindsayfester commented 13 years ago

The method above only works for textboxes NOT in an update panel. We need to manually put filters in the update panel.

lindsayfester commented 13 years ago

Edit: also, after a post-back, the filter disappears. So you need to move it outside the if (!PostBack) {} in the page load.

I'm just going to copy/paste filters for each textbook into my actual page code. It will be easier given how my page is set up.