What are the possibilities for rate limiting user input without using JavaScript? The lesser round trips made to the server for this, the better.
Without JS, they only way to do this is to validate the input on the server and send back the page with error messages for the user.
You can use maxlength but need validate in backend too.
Related
I am a graphic designer working on a website for my employer. At last minute, they have asked if it is possible to hide/reveal certain parts of a page dependent on whether the user types a specific email domain. After some research—given I am not an expert web developer—I figure out this bit of Javascript:
function validate()
{
var text = document.getElementById("email_input").value;
var formslist = document.getElementById ("forms");
var regx = /^([a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]{3,20})+#(email1.com||email2.com)$/;
if (regx.test(text))
{
forms.style.display = "block";
document.getElementById("errortext").style.visibility="hidden";
}
else
{
forms.style.display = "hidden";
document.getElementById("errortext").innerHTML="Our forms section requires an approved email address.";
document.getElementById("errortext").style.visibility="visible";
document.getElementById("errortext").style.color="gray";
}
}
And it works! But common sense tells me this seems too simple to be secure... How can I hide/hash/mask "email1.com" or "email2.com"? How could I decrease the of odds of someone just going into the browser's developer view and seeing the accepted values?
(Sorry if I am repeating this question. I just can't figure out the correct search terms for what I want to do!)
you can use digest method of Crypto API, and check the hashed input against the hashed email values
What you want is probably not possible using only a client-side approach, or else a robust client-side approach is probably overkill.
A one-way hash function is a cryptographically sound approach to allow the client to check input without revealing what the desired input is. You can send a hashed value H(v1) without leaking information about v1 itself, and then have the client verify if the user's input v2 satisfies H(v1) == H(v2).
However, what is the client then to do after verifying a match? If it's going to display information to the user, that same information must be sent to the client before displaying it. Though the page may be cryptographically sound in it's decision of when to show the information on the page, any modestly savvy user may find that information using debug tools in the browser without making the page's script render it properly.
One actually cryptographically sound approach is to only grant the client access to the secret display-information in a form that has been encrypted with a symmetric-key cipher using the output of a key derivation function (KDF) like Encrypt(secretData, KDF(v1)), and attempt to perform the corresponding Decrypt(secretData, KDF(v2)) to decrypt the data using the user's input v2. It would probably be simpler to just send the input to the server and have it decide whether to send the secret data at all, but if you have no server (or no server that you trust with your secrets, or no server you believe will stay online for the useful life of your client application) then this is a viable approach.
If you want this to be completely hidden from a "clever" user - you need to implement a backend validation. I don't see other good ways of doing this.
Javascript that runs in browser can be easily read by a user and translated into a more human readable form. So, even if you encode your strings with btoa() - it can be decoded with atob(). Example - https://www.w3schools.com/jsref/met_win_atob.asp
So this is what I would like my website to do:
The website will generate a random number between 1 and 10,000.
The website user will then guess the number that the website generated by imputing their guess into a text-box.
If the user gets the number wrong a new number is generated and the user has to guess again.
If the user gets the number right a code-number is revealed.
My problem is that if the user simply inspects the java script they will be able to see the code-number within the script. How do i prevent the website user from manipulating the javascript code to know which number the website generated? also, how do I prevent the user from accessing the code by looking at the javascript? Do i need to use php or something?
Thanks for taking the time to read my question.
first of all you don't have to generate the number until they actually guess it.
function guess(number){
var rand=Math.random()*10000;
if(number==rand){
//success
}else{
//failure
}
}
This way no number is generated until they guess and you can't inspect that.
Also thinking outside the box: Based on the conditions, the number from the guess is irrelevant. If the number changes every time, they have a 1/10,000 chance every time to guess correctly. You simply have to write a function that only succeeds once every ten thousand times. However if they are looking at the source, they might feel betrayed by this.
If you put all your game logic on the client side, the client will be able to hack your game. All major web browsers come with a debugger which could easily manipulate and navigate your client side code in a variety of different ways.
That is why the server side should be responsible for these kinds of checks and validation. If the client had to submit the number to your server, the answer could be generated on the server side where it would be safe from any tampering.
Is it sufficient to restrict user input value by setting maxlength only? Lets say I have this code:
<input type="text" id="foo" maxlength="12">
Is there any possibility that user still can (in any valid or invalid way) insert value more than 12?
When we have set the maxlength, is it usefull or useless to validate it once again using javascript or maybe at the backend (servlet, etc)?
Is it sufficient to restrict user input value by setting maxlength only?
No
Is there any possibility that user still can (in any valid or invalid way) insert value more than 12?
Yes
When we have set the maxlength, is it usefull or useless to validate it once again using javascript or maybe at the backend (servlet, etc)?
You should validate, and preferrably on the backend.
That's because you don't necessarily need a browser to pass data to the server. There are other client software, like REST testers, curl, wget, tamper data and similar software that can fire requests directly to the server, all of which bypass your maxlength attribute and JS validations.
So if you want fast validation so that the user gets a snappy, interactive response, your maxlength and JS validations does that job. But you should do a second validation when the data is passed to the server, this time for security.
It is all upon you.
Choose your datatype allowing only 12 values in database.
You job on client side is done after validation but database won't be saving values more than 12.
Before submitting a form, i use javascript code (surrounded in PHP) in order to make locally some controls but sometimes javascript may not be enabled client-side.
The fact is that I have to check by pattern/regex each control of the form for example checking email, phone number,.. format so that user cannot enter anything haphazardly. Therefore, if javascript is not enabled, the form must not be submitted, even if all field are fulfilled out.
Therefore my question is to know if there is a tag or function which allow to perform what i want to?
Thank for your help
JavaScript runs client-side.
That means that users have FULL CONTROL over it.
Then, if they want to disable it, you can't do anything about it.
The only thing you should do is be sure that users with JS disabled will be able to submit the form too.
If you use JS to validate the form, be aware that users have FULL CONTROL over it, so they can send the form if they want, even if your code says that it's invalid.
The right way to do it is:
Be sure users without javascript can send the form
Implement client-side validation for users with javascript activation. This way they will have a better user experience (because can know if the data is invalid immediately) and is less server intensive (your server will have to validate less invalid forms).
ALWAYS validate the submited form server-side. Data coming from a client is always UNTRUSTED, even if you think you have validated it.
I have a form which is submitted via mailto to a email server.
As you most know, there is a limitation to the mailto content over which it won't work because it exceeds URL characters limit.
I developed some custom data compression that are domain specific, but it is still not enough (In case all fields are filled, it will bust the limit, this is rare... but rare is bad enough for the client. Never is better.).
I found the Lempel–Ziv–Welch algorithm (http://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Welch) and concluded it would allow me to save 40% of the length average.
Unfortunately, I need of course to call encodeURIComponent to send it to mailto, and as LSW algorightm will return many URL unsupported characters this will in fact make it worse once URL encoded.
Before you tell me it would be easier to make a post to a server using server-side language, let me tell you this is a really unique situation where the form has to be submitted via email via a client-side application, because emails are the only way to connect with the outside world for the end users...
So, do you know any way to compress data efficiently without encodeURIComponent ruining it all ?
Or is there a way to send content to mailto without going through browser ?
I've seen some ways to open Outlook with ActiveX and stuff, but this is pretty browser/email client specific.
Also I checked for options where I save form info in a file using javascript... but the application users are, well let's just say they are not experts at all, and from what I've been told, they could fail to attach the email. (yes, they are that bad)
So I look for the simplest option, where user involvment is almost 0 and where the result is an email sent with the form data, all of that without server-side languages, with a compression algorithm if applicable.
Thanks a lot for your help !
You'll have a hard time getting to "never" with compression, since there will always be strings that a compressor expands instead of compresses. (Basic mathematical property of compression.)
Having said that, there are much better compressors than LZW, depending on the length of your input. You should try zlib and lzma. The binary output of those would then need to be coded using only the allowed URL characters.