Tag Info

New answers tagged

1

There is a lot of good advice in the answers above, but I'm not sure they have addressed the main part of your question i.e. limiting the number/size of input data. To recap what has been stated already Use client side input validation and feedback to improve the client user experience, but DO NOT rely on anything client side for security purposes. All ...


0

From a pure security perspective your aproach is the correct one. The web interface (html + javascript + whatever...) is just a client to your HTTP server. By other words anything / anyone can make requests by passing your client security. Therefore security at that level is basically no security. From a GUI perspective it might actually be a good idea to ...


16

You shouldn't trust the client. Writing Javascript to stop characters being entered does not stop anyone from submitting them to your search. Your search routine should remove characters it doesn't support, and when printing that back out, it should show what it actually accepted, not what was submitted. For general purpose fields in a form, consider ...


14

Your approach - if used correctly - would protect you against two very common attacks: SQL injection and XSS. And escaping/encoding/prepared statements are definitely a must-have and your main line of defense. But as you specifically mention search boxes, your approach might for example not catch SQL wildcard DOS attacks (see here and here), which could be ...


1

You should implement both measures and heres why. If you limit the character space the user can enter (a-zA-Z!@#$%^&*) for example there is less chance a unwitting user will screw up and enter some jank data. However this only really stops the end users who are trying to use your application from entering malformed data. The second step, performing ...


1

An historical example of such a poor algorithm is Microsoft's LM hash. As you said Felipe, in order to create a strong password, you need among other things to mix uppercase and lower case letters. Why? Because by doing so there can be 52 different possible letters constituting each character of the password: 26 lowercase + 26 uppercase. By converting the ...


2

I also could not find any password storage policies that mention that passwords should not be upper-cased. But I also didn't find any guides which told me not to set every password to "password", not to remove all special characters, or not to shorten them to 4 characters. It's just obvious. You should not change the password that the user supplied. This ...


0

User's Security You are missing one extremely important thing: CSRF mitigation. Be sure to fully understand the related problems. Tldr: in addition to the authorization token (e.g. session cookie), you need a challenge per action to identify if the action is intended by the user or unintended. Fix JSONP leaks. X-Content-Type-Options: nosniff, on all ...



Top 50 recent answers are included