Reply to: .NET2 Web site form - can it be Broken?

[TheFaQQer]

P.S. I'm pleased to see that a Google search for HyperGlobalMegaCorp currently shows my own site in fifth place

6th place now - this thread has overtaken it

[Durbs]

Got rid of that pesky XSS issue - I think!

Set the aspx page to
ValidateRequest="false"

You should only need to switch off page validation if something explicitely requires it, i often need to do this when using stuff like freetextbox but in your case, cant see why it would need to be switched off? Cant see many users savvy enough to actually hand write tags such as 'this site is <strong>cool</strong>'.

So i'd leave it on and clean your input as you've suggested.

[Ardesco]

Demo Guestbook Here

This is a case of diminishing returns (protection of the web form) but this thread has certainly focused my attention on areas to look at.

OK I concede that client side verification can be circumvented, but I also do some Server side checking before I even go any near passing values to the SP for writing to the DB.

Client Side
Regex, textbox length, Simple verification code needs to be typed before submit is allowed.

Server Side
Is pageValid check from client verification?
Is field size < n Chr$?
Pass field values to object (but all the types are string)
** to Do. Is email address? Is URL?, Flood control – disable DB write is excessive number of requests are made

Writing to DB
Parameterised Stored Proc with limited field size
Tightened security on DB privileges.

Finally each and every entry has to be approved (via a maintenance page) before public viewing is allowed.

I know that the page verification code can be circumvented – but it will required effort on behalf of the "baddy" to do so!


Any thing else

#

Remember that client side validation should only be there to guide the user how to fill the form out properly, and any errors displayed should be concise and easily understandable. It will not stop somebody who is attacking your site. Any validation that you perform for security purposes should be on the server side.

[NickFitz]

OK now I will weed out any <script> or </script> strings that get posted to the form.

I must admit that I am finding this form security really interesting - a great thing to play with on a Friday afternoon

Nick! - I will let your guest book entry stand, nice blog BTW

If you don't need to allow any HTML formatting, which you probably don't for a guestbook, then check out "How to HTML encode content" at the bottom of the page DP linked to above.

If you want to allow some formatting (such as bold and italic) but not let potentially nasty stuff like <script> or <object> (and actually, <img> can be dangerous in some browsers) then you'll need to do a little more work. If so, remember the golden rule: whitelist, don't blacklist. In other words, check for the stuff you specifically allow, and get rid of everything else - if you instead look for stuff you don't allow, somebody will find a way of sneaking it past you eventually.

Here's a list of known XSS vectors - as you can see, checking for all of them could get quite tiresome

[wxman]

Got rid of that pesky XSS issue - I think!

Set the aspx page to
ValidateRequest="false"

Then server side, parse each textBox.Text via

public static string stripHTML(string _ipStr)
{
const string htmlMatch = "<.*?>";
return HttpUtility.HtmlDecode(Regex.Replace(_ipStr, htmlMatch, string.Empty));
}

This strips out all the html from the string including stuff like "&gt" etc

[wxman]

OK now I will weed out any <script> or </script> strings that get posted to the form.

I must admit that I am finding this form security really interesting - a great thing to play with on a Friday afternoon

Nick! - I will let your guest book entry stand, nice blog BTW

[DimPrawn]

I made a post with the comment

testing

and got the "thank you" page. However, when I tried an XSS attack by using exactly the same details, but with the comment

testing <script>alert('pwned');</script>

I got a server error.

Posting the comment

'hello'

worked, so it seems to be be the <script> tags, not the single quotes.

By default, ASP.NET prevents script injection. It's built in, but the error needs to be handled.

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

[NickFitz]

Demo Guestbook Here

I made a post with the comment

testing

and got the "thank you" page. However, when I tried an XSS attack by using exactly the same details, but with the comment

testing <script>alert('pwned');</script>

I got a server error.

Posting the comment

'hello'

worked, so it seems to be be the <script> tags, not the single quotes.

[Durbs]

Demo Guestbook Here

This is a case of diminishing returns (protection of the web form) but this thread has certainly focused my attention on areas to look at.

OK I concede that client side verification can be circumvented, but I also do some Server side checking before I even go any near passing values to the SP for writing to the DB.

Client Side
Regex, textbox length, Simple verification code needs to be typed before submit is allowed.

Server Side
Is pageValid check from client verification?
Is field size < n Chr$?
Pass field values to object (but all the types are string)
** to Do. Is email address? Is URL?, Flood control – disable DB write is excessive number of requests are made

Writing to DB
Parameterised Stored Proc with limited field size
Tightened security on DB privileges.

Finally each and every entry has to be approved (via a maintenance page) before public viewing is allowed.

I know that the page verification code can be circumvented – but it will required effort on behalf of the "baddy" to do so!


Any thing else

I think with that lot, your client should be assured that you have taken all reasonable precautions.

At the end of the day, you WILL get idiots probing it but the vast bulk of these will be automated tools looking for common stupid mistakes.

Also the tip above is good, there is no overhead in using a replace function against input of the size coming from a guestbook form. I always do this and strip common injection characters from user input even if its not an issue due to paramatisation - belt and braces approach.

[DimPrawn]

Demo Guestbook Here

This is a case of diminishing returns (protection of the web form) but this thread has certainly focused my attention on areas to look at.

OK I concede that client side verification can be circumvented, but I also do some Server side checking before I even go any near passing values to the SP for writing to the DB.

Client Side
Regex, textbox length, Simple verification code needs to be typed before submit is allowed.

Server Side
Is pageValid check from client verification?
Is field size < n Chr$?
Pass field values to object (but all the types are string)
** to Do. Is email address? Is URL?, Flood control – disable DB write is excessive number of requests are made

Writing to DB
Parameterised Stored Proc with limited field size
Tightened security on DB privileges.

Finally each and every entry has to be approved (via a maintenance page) before public viewing is allowed.

I know that the page verification code can be circumvented – but it will required effort on behalf of the "baddy" to do so!


Any thing else

The ASP.NET validation controls generate client AND server-side validation code, so even if the client side is bypassed, as long as you check Page.IsValid before submitting the data, you should be okay.

To be sure, I run all input serverside through a regex replace to remove characters I would not expect in given fields. Eg. remove < > ? % & * etc etc from fields that contain things like names addresses, then Proper (title) case them using a very clever routine as people tend to input in all upper-case for some reason.

[wxman]

Demo Guestbook Here

This is a case of diminishing returns (protection of the web form) but this thread has certainly focused my attention on areas to look at.

OK I concede that client side verification can be circumvented, but I also do some Server side checking before I even go any near passing values to the SP for writing to the DB.

Client Side
Regex, textbox length, Simple verification code needs to be typed before submit is allowed.

Server Side
Is pageValid check from client verification?
Is field size < n Chr$?
Pass field values to object (but all the types are string)
** to Do. Is email address? Is URL?, Flood control – disable DB write is excessive number of requests are made

Writing to DB
Parameterised Stored Proc with limited field size
Tightened security on DB privileges.

Finally each and every entry has to be approved (via a maintenance page) before public viewing is allowed.

I know that the page verification code can be circumvented – but it will required effort on behalf of the "baddy" to do so!


Any thing else

[DimPrawn]

The only safe and secure solution is to have all webservers connected only to printers and not databases.

Then someone in India who we trust can read the printout and if it is acceptable, type it live into the database using a query editor.

HTH

[Jaws]

It would be a pretty bad sp to have in your app granted but i'll wager theres endless apps out there on the ole interyweb using tulipe like that.

I've actually seen that numerous times and it makes me furious!

[NickFitz]

Also use the length= attribute for your textboxes to prevent people pasting huge amounts of text in to force DB errors.

The maxlength (not length) attribute is useful for the common case of a punter with a browser, but it doesn't stop me doing something like typing:

javascript:void(document.forms[0].element[0].value="verylongstring")

into the location bar before hitting submit; last time I checked, browsers didn't enforce maxlength against that.

(Actually, the first time it occurred to me to try that, circa 1998, I forgot I was posting to the live server and crashed Oracle Web Access on a live site - still, the server restarted itself within a few minutes )

However, any malicious tool will write whatever length of content it wishes, despite the attributes of the form elements - if one is trying to break a site, one doesn't use a browser.

Remind me to tell you sometime about my XSS attack via putting JavaScript code into the User-Agent HTTP header...

[Durbs]

It would be a pretty bad sp to have in your app granted but i'll wager theres endless apps out there on the ole interyweb using sh1te like that.