Tag Info

New answers tagged


Technically yes, there is a very minor data leakage vulnerability here. In your example: "aaaaaafooNfooaaaaaaa".replaceAll("foo([A-Z])foo", "user_input") if user_input contained $1 and the value of the above was output and the input string aaaaaafooNfooaaaaaaa was not user controlled, the user would be able to find out what the original "secret" string ...


The two main risks of a system such as this are: SQL Injection XSS The risk of SQL Injection is mitigated by the use of parameterised queries. This ensures that data values inserted into the database can only be interpreted as data and not by part of the query by an attacker escaping out of the context. XSS is prevented by correct output escaping. This ...


Set <form> accept-charset Attribute using UTF-8 Sanitize all the html / xml special characters and replace them with their escaped version. Display the code within the <pre> tags


You escape the output by replacing "special" characters with their HTML character entities. In PHP, you can do this using htmlspecialchars(), for example. I suggest using the ENT_QUOTES flag to ensure all types of quotes get encoded.


Could there be some miscommunication between you and the IT department head? As Xander had already pointed out, such a scheme does not work, and I would even add that it is ridiculous. In order to authenticate a user, a database lookup has to be performed on the login email address in order to retrieve the corresponding hash used for comparison: SELECT hash ...


As far as I can tell, this scheme doesn't make any sense. As you've noted, you still need to store the plaintext email address for the user, so there isn't any significant security benefit to using the plaintext email and email + password + salt hash vs just using plaintext email and password + salt hash. As I'm sure you've already noted, without the ...

Top 50 recent answers are included