Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
One argument for using both client side validation (JavaScript) and server side validation using a validator is that if the client browser does not support JavaScript or JavaScript has been turned off deliberately, then client side validation is rendered useless.
My question is how good is this argument in practice? In theory it makes sense, but in practice, if JavaScript is disabled in the browser, then most website features will not even work. The user probably cannot even load the page without JavaScript, let alone submit a form.
Client-side validation just avoids the client from going "but I filled this all in and it didn't tell me anything!". It's not actually mandatory, and in reality, client-side validation is a very new thing (read: 5 years old or less). In practice, all it does is prevent your client (with JS enabled) to know whether the form is okay before reloading a page.
If AJAX is in the game, it is different - it allows you to save bandwidth as well as to provide user with feedback before submission.
Finally, if you're building strictly client-side, peer-to-peer exchange apps (think games), you'll want client-side validation to keep the clients from cheating.
Server-side validation is also crucial due to the fact that client-side validation can be completely bypassed by turning off JavaScript. In a way, JS-driven validation is a convenience and an aesthetic/cosmetic improvement and should not be relied upon. Furthermore, it is trivial to edit the source of a page locally in order to disable or bypass even the most complex of JS validation.
What could a user do if you do not server-side validate? Anything, depending on how you use their data. You could be allowing users to drop entire databases (or worse, leak them), modify anything they like (or worse, read anything they like. Directory traversal flaws are extremely common entrance points for naughty people), and elevate their privileges at will. Do you want to run this risk? Not validating user input is like trusting people and not installing locks on your house.
Validation should always be performed server-side - you can never trust client-side validation.
Client-side validation is always in the sense of providing a better User Experience (UX), so the user doesn't have to submit and reload a page simply because a value in a form isn't valid - it makes things more dynamic.
As you don't even need a browser to make requests, independently of your website relying on JS to work properly, you will need server-side validation and sanitize all user input in case you care about not having your databases pwned.
Now it is up to you whether you want to provide an UI with dynamic client-side validation hints or not.
Always protect your inputs on the server. It's not always about users having JavaScript disabled but also that they could break the server.
For example, if a site has a JavaScript max-length check on an <input>, a user can could disable that check, thereby sending more data than your server and/or database is expecting. This could overload the server by a large POST occupying a server thread for a long time, it could expose a weakness in the database for example violating a database constraint potentially exposing details about any persistence information. Worse, if there is no constraint a user might be able to perform injection attacks.
Another example is someone using an external HTTP tool to send requests to your server, completely bypassing any JavaScript. I use the Advanced REST Client for Chrome all the time in development for testing JSON APIs.
Client side validation through JavaScript is just a way of providing a quicker feedback to a person using the site of any information about their interaction with the site. In traditional client-server communication it should not be the only validation for the reasons outlined above.
If a user has disabled javascript is a problem of himself and he decided alone to disable the javascript for a reason... For that, when you making a website you must have always in mind that your web site must be valid for users with and without javascript. The both side validation is needed for a number of reasons, some of them are:
User has disabled javascript
An evil user in purpose has removed the javascript in order to exploit the system
With javascript validation you reducing the data traffic between the website and the client.
And of course with server validation you make sure once for all that the data are correct
It is possible to have a website that is using both javascript and "older" technologies to be valid for every user and every browser.
Client-side validation is a solution for highly interactive forms with on-the-fly field validation, but it will not prevent a ill-intentioned user from injecting and posting invalid formatted data to the server. It is important that your server-side script validates everything the user is doing, otherwise you will expose your site to SQL injection attacks, XSS attacks, users doing stuff they are not supposed to etc.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 months ago.
Improve this question
just discovered one bug in a "n" online shop. The bug is the possibility to change html code (thanks to inspect element) and make an early unavailable pickup point available. As consequence, I was able to order some stuff, pay, and even get confirmation of my order. My question is, how an owner can prevent something like this?
P.s. During ordering, I was only on the one web page, there was no redirecting to another page or refreshing the current, until payment.
P.s.s. just want to mention, that I'm a total newbie in these "magic" things. So probably you can recommend me books/webpages etc. where I can read more about "server responses".
As you found out, editing the HTML code of a site and/or modifying the data sent to or from your browser is indeed not too difficult. That's part of how a browser is designed and intended to work, so you'll have to deal with this kind of "hacking" on the server side.
Here's a very superficial (and not complete) list of things to keep in mind when setting up your server and backend application:
Every request from outside ("the client") is potentially malicious or tampered with. → Make sure you use server-side validation for "everything". This may refer to:
Input fields (length, value, format, ...)
Data formats (e. g. correct JSON/XML structure)
User authentication and authorization
Your business rules (this is, as I think, the one decisive in your example - probably everything else was valid, but the server side did not check for the availability of that pickup point you injected)
Thus, do never rely on client-side validation (typically JavaScript / TypeScript) only! You can use this for a better user experience, but the real "hard" validation must take place on the server side.
Depending on the criticality of your site and the confidence of the data associated, think about adding more security by using a Web Application Firewall (WAF), rate limiting, log crawling and other techniques to identify and block suspicious traffic.
Keep your server software (the operating system with all its libraries etc., the application server (like Apache / Nginx / WildFly / ...) and the software your site comprises of (like a Spring / PHP / Angular / ... application)) up to date. There are means and methods like Dependabot helping you to automatize this process. Outdated software and libraries might have some known bugs an attacker can exploit.
Try to use standard software, frameworks and mechanisms wherever possible. Modern Web Frameworks like Spring Boot, Laravel, ... are well-maintained and security issues are found and fixed early. Also, the have validation and fraud detection methods built-in already, you'll just have to make use of them. On the other hand, if you try to code your own authorization framework (for example), you'll most likely overlook something and leave a security gap.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I was facing to an interesting issue when implementing some role specific feature in a web site.
It's something like, if the logged in user has Admin role privileges then a button (called Transfer) will be enabled and otherwise for other user it should be disabled (So then they can't click hence can't perform the transaction / or invoke the relevant logic to that)
At a glance it seems fairly straight forward UI validating kinda stuff. We just has to enable the button if the logged in user has the Admin privileges.
So after implementing that approach (working fine) , I was debugging the code using Chrome developer tools. I noticed that though the button is now disabled we can actually enable it by removing the disabled part using the tool.
Just try it with this simple fiddle
And then I can click on it and the functions get invoked. So basically it was not good approach. But fortunately there are service side validations also. But if not this can be a huge security vulnerability.
So basically doing an server / service / back-end validation will prevent something dangerous from happening. But since the person can actually click on it and at least he can try to invoke the methods it seems not nice :(
So , I would really like to know , How can we prevent these kind of situations.
okay here is my question in simple :
Is it good to have Disabled components at all?
"Don't" use disabled components in your View.
That's part of your business logic and should not appear in the DOM...
"But hey :)..."
Now, even it the element does not exists, nothing can stop a user to manually embed such element into your website.
You should always perform server-side checks to see it such user has the actual privileges to perform a specific action.
Sometimes disabled elements are used inside the UI to show the user:
"Hey, see this button? It's not for you unless you pay or blah blah",
but usually as a second-step/optional action element.
Sometimes entire forms are "visible" on websites but dimed-out / disabled.
Such use cases are i.e: Payment forms with steps, where the designer wants to make wisible to the user that he needs to fill in a previous form in order to "Activate" the second one and proceed with the payment etc... Cases are endless, but if a form exists on the website it's pure UI (View) and the Model should never accept values from the controller unless (as I've said) specified by the Business Logic.
Remember that Front-end Javascript is used just to inform and help the user trough intuitive interface systems. JS events should just be there to reflect what a user can and cannot.
Since JS can be bypassed by any tech-savvy user, On the back-end side, you need to rebuild a similar and stronger security logic, once again.
(!) Validate user inputs on front-end, but most importantly - in back-end.
Can firebug or developer tools use to hack a web site?
Directly?
Yes
If the website back-end logic can be exploited by manipulating the View (source).
If you keep in the code that gets to the browser (in comments etc) sensitive informations.
No
If a website does not allow XSS, has a strong back-end security.
Indirectly?
A malicious user could eventually ask a user to open console (tricking the user that Console is an actual website feature) and to send him (copy/paste) private information that are present in there, such as session keys, cookies, etc...
When the request is received by the server you should check if it is valid because I managed to get the button working in less than 10 seconds.
Depending on your server side programming language, you could use templates to generate your HTML pages so the componentes that are not allowed to certain users wouldn't even be rendered in the first place.
For Java, you have JSP/JSTL or JSF, for .Net you have ASP.Net and MVC.
You should absolutely validate everything that has to do with logins/permissions on the server side. Even if you change the site so that instead of disabling the element you never attach it to the DOM in the first place a tech savvy user can just try sending different data to your server and soliciting for meaningful response using wget or curl
How do you prevent these situations?
Should you have disabled components?
The first questions answer gives you the second questions answer.
You shouldn't do this on the client side. However this is a common case and it's always recommended that you have server side checks in place to accommodate for people using developer tools to get around these things.
Another approach besides not implementing this is to abstract it.
If the user hasn't logged in don't even include the button in the DOM.
When they pass the specific parameters needed to give them the button you can use javascript to make a server side request, validate this and then inject the button appropriately, even in this case you should have another server side request validating the action after the button is triggered.
Fulfilling button show parameters
Validate
Inject button
Trigger button
Validate
Perform action
It really depends on how your application is laid out. In reality if you don't include the first two steps and only hide the button before validation there isn't any change in your application UX unless developers are a part of your audience because developers love to break things.
Can firebug or developer tools use to hack a web site?
If the applications data hasn't been secured or validated on the server then yes.
You should always check data coming in and validate it no matter the source external or internal.
Validation is your friend.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
when i use asp.net to coding for website. Asp.net in server call sql server (ado.net, linq or entities framework) and get back data, send for clientside. i use some control as girdview to show data. actually, i do web optimization ( sql server - store procedure, create index, partition => faster, acceleration for get data. Website: UI simple, do not use too many effects)
but why in client-side, when server return data for client, many people always are going to use script (such as javascript, jquery, node js, angular js, bootstrap, react, google o/i....) to show in webpage.
so, it slower or faster when we use girdview?
And when User (people in clientsite) stop scrip in browser, it's mean, Manufacturers allow user or offer to stop script on browser in clientside., so why do we user them ( *.js), when User can stop script?
Even many people use asp.net (new version - 2013) in server, they also use script in there. so asp.net + script in server is faster or slow when we only use asp.net?
please, help me answer.
(I'm apologize because my English is not good.)
Thank you so much.
In the early years of Web development, Javascript on the client side provided for considerable enhancement of the client's "user experience" that static HTML delivered from the server did not. This includes such things as the enabling or disabling of certain interface features based on user input, the appearance or hiding of certain regions of a display based on user input, or combination of other pieces of data.
As web development evolved, the need for even more robust client-side interaction with back-end web servers became evident, and the "frameworks" you mentioned all work in various ways to improve the design, responsiveness, and behavior of a web-based application in ways beyond just enabling or disabling a button. This amounts to complex data binding, callbacks to web services, reducing server round-trips, and creating rich client interfaces, to name only a few.
They're all tools, each with their own role, each working to make web applications a bit more robust than those of the generation before them.
If I understand your question right, the answer comes down to speed and preference.
Firstly, if you disable client-side javascript, your asp.net controls aren't going to really work anyway. You'll find few places that still disable this so it's not really a concern people have anymore.
Secondly, it comes down to where you want to focus development effort and what kind of developers you have. If you have a lot of people used to working backend (C#) and want to stay there, then using asp.net controls and the like make development easier.
If you have javascript developers or people who want to use it, then you have more options that allow you to more decouple your server-side code from your front-end code. This can work out well for maintenance purposes.
The real point is that if you can utilize ajax (http://www.w3schools.com/ajax/default.asp) within your web application, you can make it a lot more responsive. ASP.NET Controls can often cause your page to refresh and cause unnecessary server-side computing to get the data and re-render the entire page (or partial page with asp.net mvc). Using new technologies like angular and others you listed, you can focus data computation and network traffic only on what's important.
For example, if you need a table to change what data is loaded, you can make an ajax request JUST for the data you need to load and then just render that portion on the client.
First of all, every "script" you mentioned (jQuery, AngularJS, Bootstrap, React) is a library written in JavaScript. Except node, which isn't even front-end. And I'm not sure what did you mean by google o/i... JavaScript is currently the only language which works in all browsers.
Initial purpose of JavaScript was to check form values before sending data to servers. It quickly evolved past that, although the usage was throttled by browser adoption, which is still a problem today.
Nowadays we can use JavaScript to render whole webpages. First when opening the page, it can help with rendering, meaning that server doesn't have to do all the work, but can just send plain data, usually in JSON. It's also used to add content to page later, without reloading the page (AJAX). Most well-known examples are real-time chat systems, like the one on facebook. This greatly improves user experience, I can't imagine how terrible it would be if whole page would reload to display a single new message.
Although user can disable JavaScript in their browsers and this would mean the page probably won't work, except if there is fallback design for such cases, I do not know why would someone disable it. And to be honest, probably most of the regular users don't even know this can be done and where is the setting to disable JavaScript.
I have a form users fill out and JavaScript is used to validate the input (e.g. makes sure the password field isn't left blank). Since JavaScript is client side and not compiled anyone can easily mess around with it. Does this mean it's necessary to validate data from the user again on the server? If yes, is there anyways it can be made more efficient since JavaScript (theoretically) already did it?
Yes, it is necessary to validate data on the server because it can be messed with by end users client-side.
If yes, is there anyways it can be made more efficient since JavaScript (theoretically) already did it?
It is already more efficient than having only server-side validation, because you avoid a lot of round-trips for validation by having client-side validation (you only need to submit the data once, and unless validation was incomplete or disabled, it will go through straightaway). Provides a better user experience, too.
You cannot do away with server-side validation (if you care about the data). If the data only ever goes back to the same user and is not shown or used anywhere else (and has no potential to break anything on your system), you could relax this a little. As as extreme example, Dropbox probably does not care what files you upload, so they don't validate if the HTML you upload contains malicious Javascript.
I can disable any javascript on your page just with a click of the mouse. I can even totally bypass an HTML form and send data directly to your server.
For example, if you retrieve data with $_GET I can bypass your form (and the javascript validation) just by messing with the address bar. Don't think that using $_POST would change this: it just a matter of writing an HTTP request.
So, yes... Never trust user input, even if sanitized with javascript.
As somebody posted above, javascript validation can prevent legitimate user errors (thus save the trip the wrong data would have done to your server and then back to the user) but malicious users will still be able to bypass it VERY easily.
short answer: yes and always!
read about PDO, SQL injection, UUID, tokens, MD5, SHA, Cross-site request forgery...You have a whole new world to discover! :) I mean it in a good way. Learn about this and you'll build more secure websites
You always need to keep this in mind: Never trust user input data. Never. So you have to perform extra validating process in server-side.
Yes absolutely. It is still possible for someone to intercept the form and modify values before re-posting to the server.
The user certainly can disable JavaScript. It is also very easy to mess with it as the source code is right there. The user can also run arbitrary JS, making it even easier to mess with your stuff.
Therefore, you should always do server side validation as well. Client side validation should only be used as convenient information for the user. Never trust it as your only security source.
Yes, you MUST validate both in client side and server side.
You must think in terms of progressive enhancement. Think of Javascript as just a layer for enhancement and not a necessity. Because it's always upon the discretion of the user to disable Javascript in their browser, rendering your Javascript code useless.
A plus in client side validation is you're saving roundtrips to the server validating if the username or password is empty which can easily be done in javascript.
Yes, to be safe you will need to add server side validation.
Nothing that is expected to have been done on the client side is guaranteed so you will need to repeat anything that is important.
Additionally there are things that are likely to be evaluated on the server side but not on the client side. Things like checks for SQL injection fall into this category.
I use some jquery and JS functions to validate forms and to check for example if that field is empty or password is less than 6 characters, and stuff like that, and I noticed that if someone disabled JS, then these functions would be useless, and no more protection of forms, which can be better made using PHP, so should I avoid them now because this could cause an insult to my website ?
JavaScript is very useful for improving user-interaction, along with reducing the number of requests made on the server; but, as you've pointed out, it can be disabled. To answer your question: No, I wouldn't recommend avoiding the use of JavaScript, but the key is not to rely on it for critical actions, such as validation. You'll want to implement the validation on both the client (JavaScript) and server (PHP) sides. This will ensure that there is no way for the user to completely disable the validation.
In short:
JavaScript = Good
JavaScript Validation = Nice for the user, but not reliable
Server Side Validation = Essential
Side note:
With regards to relying on JavaScript for the overall user interaction, as other answers have suggested, use JavaScript to enhance the overall experience, but don't rely on the user having it turned on. I would recommend a bit of bed time reading of Progressive Enhancement, it's the approach of making something better, with being reliant on it, and can be applied to more than just JavaScript (CSS3 etc).
You should use javascript and jQuery to enhance the functionality of your site. If someone has javascript turned off you should ensure that the site still works, and they can access all areas - even though there may be some things they cannot see, such as transitions and effects.
With regard to validation, you should ALWAYS validate server side. Client side validation is optional, but a very nice feature to improve the user experience for your visitors.
I don't mean this as a complaint, more of an observation.
Web developers often grab Javascript libraries as the latest shiny toys with no thought for the consequences. As a Data Governance person, I'm regularly the bringer of bad news, when we do audits on the data collected, and find users who get past the Javascript validation.
"Go back and start again".
Javascript libraries are great for the presentation of data, but should and must not be relied on for data validation and the integrity of user profiles.
A validation should always happen at
Client Side - using javascript to enhance the user experience.
Server Side - using the preferred server side programming language for security reasons
Service Side - if you are following SOA / Web API as part of defensive programming practice. This can also be at the DB level along with Service layer.
You should not avoid using JS and jQuery in your website, but you should avoid using them for validation purposes or business-logic purposes. These should be done in the back-end of the website, not in the UI level.
You shouldn't really avoid them. What you should do is to implement both client and server validation. Don't rely just on client validation, for the reasons you just mentioned. You should always validate the data when it arrives to server.
Adding client-side validation gives your pages dynamic look and feel. A user does not have to wait for the form to go to server and in case of an error to return back. It is automatically verified without postback.
As I said above, don't rely upon client side validation. Always implement server-side validation also.
Remember my friend, Java script is client side scripting. its purpose to validate form at client side itself so we can avoid overhead...You must use java script at client side. because PHp is server side language. It will take time to reply.
Ha, Server Side validations are equally important. if you want to do that, then you can use server side language. You can check comment below to my post by halfer. Server side validations are important for security and many more purposes.
That is different thing that somebody disabled js. You can check for the same and give proper message to enable.