Tag Info

Hot answers tagged

12

actually, hashing it MANY times is bad. here is a quote from http://yorickpeterse.com to proof that. "To cut a long story short, hashing a hash N times doesn't make your passwords more secure and can actually make it less secure as a hacker can quite easily reverse the process by generating hash collisions." read the full explanation at ...


5

Assuming your server doesn't use any credentials besides system-level accounts and the MySQL password, there's one thing you need to protect: the swap file. Programs are supposed to take steps to prevent credentials from winding up in swap, but they don't always do so. There are some sensitive things in /dev and /proc (such as /dev/mem and /proc/kcore). ...


4

When you use a re-webber proxy (a website where you enter a URL and it shows you the content of that url in its own context), using TLS between you and the end-website becomes impossible, even when the proxy would want to provide it. When you enter https://google.com in the proxy you linked, you get redirected to ...


4

I would recommend against using sha256 for hashing passwords. The sha2 suite is designed to be fast - exactly the thing you dont want. In short, use bcrypt: http://stackoverflow.com/questions/4795385/how-do-you-use-bcrypt-for-hashing-passwords-in-php In a proper KDF, iterations are similarly included to slow down the process of password hashing (to answer ...


3

Unlike unserialize, if you execute json_decode alone it will not be able to instantiate any different variable types besides simple ones (e.g. arrays, string, int, float, etc), so it is fairly safe to run it with user input data. The problem in your code is with the e function. If the parameters you pass to it come from an untrusted source such as user ...


2

Your assessment sounds correct. It's impossible, of course, to say that your server has not been compromised, but by default, PHP receives all the data before executing the script, so it writes file uploads to /tmp and provides that filename to the running script. If your /tmp is mounted with atime enabled, the fact that atime==mtime is reassuring. If the ...


2

These requests seem to try to locate Ajax File Manager, in which several vulnerabilities have been discovered. If you don’t use that, there is no need to worry.


2

The security gain from hashing 90,000+ times is basically minimal.In fact it's actually less secure since any prospective hacker can crack it easier by looking for collisions. You may as well use a higher hashrate (i.e sha512) and therefore have a longer hash rather than just looping through and appending previous results. All your loop does really is ...


2

for XXE please read: http://www.ubercomp.com/posts/2014-01-16_facebook_remote_code_execution http://blog.h3xstream.com/2014/06/identifying-xml-external-entity.html i can confirm a similar attack worked on Java/Tomcat And then there is a Billion Laugh - Attack ( i think this was what Bruno referred to) http://en.wikipedia.org/wiki/Billion_laughs


2

Seems that my comment did not make it here, so i'll post it as an answer: No, it is not a serious security concern. If your site has for example a blind sql injection vulnerability, this would make it easier to attack a specific user. It probably also makes it a lot easier to scrape your website for user profiles, if that is a concern of yours. But other ...


1

Using POST instead of URL parameters has zero benefit for security. POST data can be changed just like URL parameters. In fact, you must not trust any data coming from the user, be it a URL parameter, a POST parameter, a cookie, an HTTP header or whatever. Almost all input is under the user's control and can be anything they want. The key is to treat every ...


1

I'm the author of the OWASP page about PHP Object Injection. Like already said by Guilherme Sehn, json_decode will not allow for object deserialization, and the snippet code you've posted contains a vulnerability which doesn't concern PHP Object Injection. So, I think it's correct to say that using JSON functions is enough to prevent object injection ...


1

The way we decided to address XML expansion and XXE vulnerabilities is to search for the !ENTITY and !DOCTYPE substring in the XML. If they exist, the XML was sent by an attacker because they are not sent by the application. We also decided to count < and > in order to protect from an attack like @Bruno Rohée suggested and only parse the document if ...


1

fix for what? serialized objects might be usefull, but you should just never ever unserialze() user-input; this WILL fail and there WILL be a smarter guy that will find this vuln. the OWASP-page is very wrong (IMHO): it just should issue a BIG RED WARNING: DONT USE UNSERIALIZE ON USER DATA or am i wrong here?


1

Did you say something about running phpMyAdmin? Is its directory standard and/or publicly available? (even if [you think] nobody has the password). phpMyAdmin is usually an attack vector on web and database servers, and its existence is widely searched for on automated crawlers. Is the server compromised? As David said, we can't tell whether it was or not, ...



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