• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

You are not logged in or you do not have permission to access this page. This could be due to one of several reasons:

  • You are not logged in. If you are already registered, fill in the form below to log in, or follow the "Sign Up" link to register a new account.
  • You may not have sufficient privileges to access this page. Are you trying to edit someone else's post, access administrative features or some other privileged system?
  • If you are trying to post, the administrator may have disabled your account, or it may be awaiting activation.

Previously on ".NET2 Web site form - can it be Broken?"

Collapse

  • TheFaQQer
    replied
    Originally posted by NickFitz View Post
    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

    Leave a comment:


  • Durbs
    replied
    Originally posted by wxman View Post
    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.
    Last edited by Durbs; 12 December 2008, 18:55.

    Leave a comment:


  • Ardesco
    replied
    Originally posted by wxman View Post
    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.

    Leave a comment:


  • NickFitz
    replied
    Originally posted by wxman View Post
    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

    Leave a comment:


  • wxman
    replied
    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

    Leave a comment:


  • wxman
    replied
    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
    Last edited by wxman; 12 December 2008, 16:27. Reason: added more stuff!

    Leave a comment:


  • DimPrawn
    replied
    Originally posted by NickFitz View Post
    I made a post with the comment
    Code:
    testing
    and got the "thank you" page. However, when I tried an XSS attack by using exactly the same details, but with the comment
    Code:
    testing <script>alert('pwned');</script>
    I got a server error.

    Posting the comment
    Code:
    '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/

    Leave a comment:


  • NickFitz
    replied
    Originally posted by wxman View Post
    Demo Guestbook Here
    I made a post with the comment
    Code:
    testing
    and got the "thank you" page. However, when I tried an XSS attack by using exactly the same details, but with the comment
    Code:
    testing <script>alert('pwned');</script>
    I got a server error.

    Posting the comment
    Code:
    'hello'
    worked, so it seems to be be the <script> tags, not the single quotes.

    Leave a comment:


  • Durbs
    replied
    Originally posted by wxman View Post
    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.
    Last edited by Durbs; 12 December 2008, 14:51. Reason: typo

    Leave a comment:


  • DimPrawn
    replied
    Originally posted by wxman View Post
    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.

    Leave a comment:


  • wxman
    replied
    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

    Leave a comment:


  • DimPrawn
    replied
    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

    Leave a comment:


  • Jaws
    replied
    Originally posted by Durbs View Post
    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!

    Leave a comment:


  • NickFitz
    replied
    Originally posted by Durbs View Post
    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:

    Code:
    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...
    Last edited by NickFitz; 12 December 2008, 05:23.

    Leave a comment:


  • Durbs
    replied
    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.

    Leave a comment:

Working...
X