Tag Info

New answers tagged

0

Of course I cringe at the idea of a simple hashing over a passphrase, but let's assume that it is actually OK in your setup. The direct answer to your question is simple: practically, there are no collisions in SHA-256, regardless of input length. If you input two distinct sequences of bytes (e.g. two passphrases), you will get two distinct output. ...


1

There are cases of SQL Injections leveraging the implicit conversion of Unicode homoglyphs from Unicode character string types (NCHAR, NVARCHAR) to character string types (CHAR, VARCHAR). A character such as ΚΌ (U+02BC) in NVARCHAR may slip through the escaping routine and get translated to ' (U+0027) in VARCHAR, which may result in an SQL Injection when such ...


2

Please, please, please, please do not use a handmade regex for preventing SQL injection. You should never be writing your own escaping, filtering, or sanitizing functions to prevent SQL injection, XSS, shell injection or the like. These are things you rely on built in and vetted libraries for. Where you can avoid it, don't even use a standard library ...


2

If you're looking at how unicode can be exploited, see this question, if you're looking for a solution, there are really only two that can be considered really secure: parameterized queries and encoding all of your input into hex or base64 or some other encoding that doesn't leave open the possibility changing the context of the value. I would seriously ...


2

The one thing you need most to stop SQL injection is a semi-colon (;). However, it isn't always simple to just eliminate them. You will have situations where a semi-colon is used in a text field as a character, not as a SQL command terminator. There are plenty of articles that go into detail about how to both inject and prevent SQL in your queries. ...



Top 50 recent answers are included