I was recently messing with a django local server project and I had a input like
<form....{% csrf_token %}
....
<input type="text" value="foo" readonly />
....
</form>
Now the value of the input should stay the way I want it to ("foo"), but I used google chrome inspect and was able to change the value of the readonly input and pass the new value to the server, which saved the bad value.
So I have a few questions:
What are the general rules or mental checklists to prevent security risks like this?
Could I use the JavaScript console and corrupt data like this as well? Update: YEP.
So do I have to basically do all my checks on the server side?
If no to 3, what are the client side validations that are protected from html/js inspectors?
Edit:
I'm guessing from the answers so far, it's yes to 3. So should I still bother with client side security/checks? Will they actually make me more secure or is it just a false sense of security (which is bad)? Should I do client side checks to possibly save some checks on the server side, so my performance might be better? Basically: How much client side checking should I do?
You cannot reply on Javascript or anything on the client side for security. Just ensure that your server is secure.
For example you can just telnet to the port and send the appropriate data to the server. This will thwart and checks via Javascript (or any other technology( on the client side.
Just use Javascript to make the users experience on the client more enjoyable and more responsive. Do not use it for security.
Ask yourself why you needed that readonly value in the first place. Presumably, it was your code that generated it, when the user first requested the form. So, what was available to your code when the user requested the form that is not available when the user submits it back? There shouldn't be anything, which should lead you to the conclusion that that field can just as easily be generated on submit, without it needing to appear in the form at all.
Your server code must be the final authority, it simply cannot rely on the quality of validation that the client has done. View all clients, be they HTML or otherwise as prone to the effects of both devious users and fallible coders.
Never believe the data sent by a user (cookies, session,parameters in HTTP request,...). All data send by users can be modified.
Yes of course
It is still to be done.
Related
I have a login and signup forms i handle validation with JS like showing user messages if email isnt in the right form also minimum characters number etc , the question is as everyone says we must add a server side validation to stay safe from the case user changed or disabled JS in browser , but does that means i dont need and its impossible to show this errors to client side in case he disabled JS cause its disabled ? in general do you write some logic code for that kind of simple form validation errors to user , or this validation errors are only important for developer? if user disabled JS i think react app wont work either so that doesnt make sense and thats what i see
The Server validations are just there to make sure that you are safe that basically means you should not rely on the front-end validations at all. However, you can validate the request with Clientside/JS as well so you won't need an extra call to API to validate the inputs.
In-case of disabled Javascript, you may ask the user to enable or otherwise, you will not be notified of any error.
<noscript>
<span style="color:red">JavaScript is not enabled!</span>
</noscript>
Server-side validation is must-have. It must be implemented always as it's only guaranteed it cannot be skipped.
Client-side validation is just for user's comfort, he doesn't need to send a request as basic mistakes can be catch during inputting data. Remember that it can be skipped easily within a common browser, so you cannot rely on its safety.
Always best solution is combining both: client-side for comfort and server-side for security.
is it safe to send the data(text) of div to the server via ajax? or get the url of an <a> tag and use it?
ex.
<div id="get-value">Some Value</div>
<button id="send" data-url="process.php"></button>
javascipt
$('#send').click(function() {
$.ajax({
url: this.dataset.url,
dataType: 'json',
type: 'post',
data: {
value: $('#get-value').text(),
}
});
});
What if I edit the text in the div and the data-url of button in the developer tools and click the button after?
It is safe to do this.
When working with Javascript and AJAX, you are subject to this inherent problem: it can always be modified. The best way to minimize the issue is to make sure that no secure operations occur on the client, and instead let the Javascript do the display and submit.
In this case, you can leave it as it is. As long as you are sanitizing the user input on the server side then you are doing most all you can (aside from obfuscation, which is rarely a good idea in Javascript).
In my opinion, and I'm no security expert but this is how I deal with things, you should always validate and sanitise user input on the server side. If a user can submit data, they can tamper with it, so it is not safe until you have cleaned it up and made sure it is safe on the server.
I don't know what you are using for your server side, but most frameworks these days have built in ways of sanitising user input before committing it to, say, a database. I would look into the documentation of your server side language/framework to find out the best way to handle incoming user input safely.
is it safe to send the data(text) of div to the server via ajax? or get the url of an tag and use it?
Yes.
Note, however, that since it is coming from the browser, it is user input and should be treated as such. You can't assume that data you gave to the browser with the expectation that it would be sent back to the server isn't going to be tampered with.
Don't use such for things like authorisation. You can't trust the browser to tell you if the user is an admin or not. You need to have proper authentication and then do the authorization for the user on the server.
Don't use it without suitable escaping for the purpose. e.g. Don't stick it into SQL without using a bound argument. Don't stick it in HTML without converting special characters to entities (or using a HTML parser with a white list filter to clean out XSS risks).
I just discovered a bug which I couldn't find any solution of, I would like your advise on that. Issue is there are a few hidden input types, which are there to store ID's of already saved data such as per person id if it is already saved etc. etc.
I just tried and change the value of that hidden variable manually, using google chrome and submit the form and surprisingly i did not get the id that should be there but instead i received the Id that I changed. for instance there was an value of 22 I change it 263 I received 263, whereas I should have be receiving 22. I want that 22 to come not that 263.
Its hard to explain I know but I have tried my level best to convey my issue please help and advise my on that how should I store some hidden value that are un-editable.
Any Idea?
Rule of Web Development #1: Never trust the client
Rule of Web Development #2: Never trust the client
Rule of Web Development #3: You can't make the client trustworthy
If the user shouldn't be able to edit it, never give it to them.
As others have said, there are a few ways to handle the situation. The most common is to use a SESSION variable on the server, available almost everywhere.
Store the "secret" values on the SESSION. They will be available when the user posts back.
You cannot control what data users put in HTTP requests to your server.
Instead, use authentication and authorization, on the server, when the request is received, to make sure that the user is allowed to submit the values they submit.
If you're wanting to keep track of data from one page to another I would use sessions. This is data that is tracked on the server.
//page one.php
$_SESSION['id'] = 22;
//page two.php
echo $_SESSION['id']; //22
This is a basic functionality of how browsers work - essentially someone could POST data pretending to be your form with whatever values they wanted in the fields - or even add extra fields.
If it's a problem consider moving that data from hidden fields to session variables.
If it's important for your hidden fields to be secure, don't contain them on the client-side. Client side variables are pretty easy to modify.
You should probably store them in your session, so they're not outputted to the client. If they're required on the page, use AJAX to grab them instead.
It kinda depends on the domain of your application, if it's in-house software then I wouldn't worry about it particularly.
It does not look like a bug.
What scares you about this? These fields are not going to be accessed and changed by your visitors. If you're afraid someone is going to hack the http request of your visitor and change his order (for example), then https connection should help.
Is it recommended to make all the necessary input validations in client side? I want to optimize the processing of the server (meaning lesser double validation so that the programmer may focus only to business logic).
Example:
On the client side, there's an 'Age' input textfield (JavaScript will not allow to submit the form unless it's within the range)
On the server side, there's no more validation of the 'Age'
// instead of validating again the age
int age = Integer.parseInt(request.getParameter("age"));
// check age if valid
if(age >= 0 ) { /* codes * / }
We can instead proceed only to
int age = Integer.parseInt(request.getParameter("age"));
because we are very sure that it is valid.
To accommodate disabled JavaScripts in Web browsers, we need to check first. If JavaScript is enabled, proceed to the application, otherwise block the application. (Just like Facebook)
Is my theory / concept acceptable?
If you need to enforce certain input patterns, you cannot rely on data that comes from the client. Folks can disable JavaScript, or simply bypass your validation completely and send whatever data they want. However, most casual users will not have this problem, and the data is coming from the client anyway.
In short, it depends.
For most of my applications, I have client-side validation and only worry about some things server-side that can throw an error condition. For example, if I have a form that sends an e-mail to someone, I will have JavaScript that checks for a valid to: e-mail address, and alert the user. Server-side, if that e-mail address isn't valid or isn't present, I will simply throw an error writing code to let the user nicely know something has gone wrong. For the message body, I'll validate client-side whether or not it has one, but server side I won't really care. Again, what you do depends on your needs.
I believe in validation EVERYWHERE
I like to have client side validation for:
required fields populated
minimum size fields (like zip)
Regex for proper character types in proper locations (eg social security numbers, new passwords, etc)
privilege enforcement (users can only see and do what their role should be allowed to)
Server Side validation for:
all client side requirements
entity associations (child-parent relationships are legit)
changes or requests are Role-Authorized
User Entry is the enemy! Users will find a way to break your site willingly or un-willingly. Things will fall through the cracks. So I strongly endorse double and triple checking.
I would believe in client side validation to save server processing, if it NOT for my fear that this kind of thinking will make me exceptions more prominent.
Overall, the reasons why I value rich Client side validation are:
one more level of checking data integrity (as well as server side)
guiding users; intelligent client side validation makes helps users make more efficient answers quicker
a better experience; If users don't have to wait for the loop back to server and returned to client to see their errors, their user experience should be better.
If security / data integrity is a concern, I would advise against this. While it'll be enough to prevent Joe Smith from entering unwanted data, you'll leave your system open to serious data manipulation from people who understand how the web works.
Let's say you have a voting system like on StackOverflow where anytime a user votes, an AJAX call is made. While the JS validation may prevent a person from using the displayed HTML to cast multiple votes on the same question or answer, it will not prevent a user from going into their browser's console and manually submitting POST or GET requests to get around the JS validation. Before you know it, you'll see Lloyd Banks with 100k reputation after answering just a few questions
I have an application with reflected XSS vulnerability caused by an unvalidated url. I want to provide atleast output encoding in the client side. I have access to modify only the front end pages which are in html and js. I do not have access to backend application code , so I cannot use UrlEncoder.encode at server side.
My question is how can I call server-side encoding from client side forms.
I know in jsp I can write
<#page import=org.owaps.esapi.*
var url = <%=Esapi.Encoderr.encodetoUrl(vulnerableUrl) =%>
But since my webpage is not jsp , but html+js , how can i call a server-side encoding function?
Given the information you provided I would say no, it's probably not possible.
Let's say you add:
document.forms[0].redirect.value = encodeURI(malcious url)
Now the attacker comes along and sends in:
"); alert("xss")
The problem is that the malicious data is already in the page when the client script runs, and would already have altered the layout and contexts of the page.
I think there would be a better chance of fixing this by employing a WAF like mod_security to limit the prossible values that can enter the app, then trying to fix it client side. Though actually fixing the problem server side is the best option.