-1

I totally understand that JavaScript should be used to enhance a users experience, however I use it sometimes to validate the input for example to check if the password textbox is more than 5 characters or to check if the username entered in the username textbox already exists. As you can imagine if the password is less than 5 characters or the username already exists, the register button is disabled.

However, this can altered from the users browser, so is their any better way of validating the user's input?

I understand I can validate it all through the server just by checking text boxes when the register button is clicked but surely their must be better ways as such that a user cannot alter?

BTW: I'm using Visual Studio C# ASP.NET

Also, am I correct to think that regex expressions can also be altered at the clients side

kguest
  • 3,804
  • 3
  • 29
  • 31
mogorilla
  • 195
  • 2
  • 13
  • You're correct to assume that everything form the client-side is untrusted. Even things like radio button groups or checkboxes that can't be modified without editing the dom. Yes, the regex expression can be modified. You need both client-side (UX standpoint) and server-side (actual security) validation. – jdphenix Jul 11 '15 at 22:14
  • 1
    The basic rule is Never trust the user. Anything you place in the browser is capable of being manipulated by anyone after it leaves your server. So the accepted practice is to do client-side validation as a user-experience mechanism ONLY, and to do server-side validation as the actual validation. – Sam Axe Jul 11 '15 at 22:14
  • Whatever you do or you don't do client side, you should *also* have stringent server-side input checks. The server is your last - and best - defense against illegal inputs. And yes, just about anything can be altered on the clients side. Pretty much the same is true of the URL and HTTP payload, too. That doesn't make using Javascript regex any less effective... Trust Nothing ;) – paulsm4 Jul 11 '15 at 22:15
  • You can explore this by using developer tools in your web browser (hit F12) to edit HTML and JavaScript. Go ahead, bypass some client-side validation. – Tom Blodget Jul 11 '15 at 22:47
  • Independent of the need of server side validation I think it's worth mentioning that you should only do client validation of things which the client _can_ do. Length of a password is certainly one of these things. Checking if a user name exists is definitely none. Under no circumstances shall the client know existing user names and client side validation should not cause any server roundtrips. – Bill Tür stands with Ukraine Jul 12 '15 at 08:04

3 Answers3

5

Validation should be done on both the client and the server. If you choose not to use a framework that has built in validation you can definitely write your own regular expressions to do this.

Client side validation can be bypassed and its main purpose is user experience. See here. Server side validation is tougher to bypass.

Community
  • 1
  • 1
  • You're absolutely correct. Also, a shameless plug for [OWASP Top 10](https://www.owasp.org/index.php/Top_10_2013-Top_10) (*MANDATORY READING*): https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project – paulsm4 Jul 11 '15 at 22:19
1

Never ever depend on client side validation. There must always be double checks, one on client side and one on server side. Java script, J query and regular expression can do that for you. As a side note, USE PARAMETERISE QUERIES.

-3

It's true that the nature of client-side code is that it is manipulatable. You can get close to preventing alteration of code through the console by using Private and Privileged members of a function. Within the constructor, privileged methods are assigned this and only call private variables. Take this example from crockford.com,

function Container(param) {

    function dec() {
        if (secret > 0) {
            secret -= 1;
            return true;
        } else {
            return false;
        }
    }

    this.member = param;
    var secret = 3;
    var that = this;

    this.service = function () {
        return dec() ? that.member : null;
    };
}

The service function is priviledged and is able to call the private dec() method, which has access to the private secret variable. service is a privileged method because if directly called, it will return null.service rather than the desired value of the variable it has access to, secret.

You can use this to your advantage when evaluating passwords because server-side code can require specifically structured data that, without proper javascript, will simply not be accepted.

74U n3U7r1no
  • 309
  • 1
  • 13