Tag Info

New answers tagged

3

What if they entered their email as "></a><script>alert("XSS")</script><a href=" which (might) be rendered by the application as <a href="mailto:"></a><script>alert("XSS")</script><a href="">"></a><script>alert("XSS")</script><a href="</a>. giving rise to a Stored XSS ...


-1

you put user input directly into a DB?... Bad idea (in general). You should sanitize all Input. (so input coming from the client and input coming from the Database). You are relying on the Client to make values safe in your example. something you should never fully trust as its outside of your control. for the rest I defer to @SilverlightFox as his ...


1

There's no such thing as special characters. It all depends on the context that input is used within your application. Protecting against SQLi and XSS is great, however if then input is then to be used in an operating system shell call it does you no good. Always encode or sanitize when the data is used - leave this as late as possible. For example when ...


1

There is no doubt that the white-list approach remains the best one (actually I would even add a maximum size limitation to this regex, I guess a legitimate login counting several hundreds of characters should not be so frequent...), because it will protect you also against a range of unsuspected exploits and brings you some level of trust that the login ...


0

Here's three ideas. Use a CA As the commenters already said: Have them trust a CA. It's less painful. And it scales much better. Each participant will only have to verify the CA's authenticity once and then they can communicate with every other participant. (Then of course, you will have to trust the CA, very, very much. -- But I consider this a good trade ...



Top 50 recent answers are included