Tag Info

Hot answers tagged

46

Why are you refusing to use TLS? It works, it has a good track record (some minor exceptions aside). Refusing to use good tools without a compelling reason does not engender confidence and does not immediately suggest professionalism. Additionally, do not roll your own authentication system. That is silly, and you will make mistakes. Instead, since you ...


17

SSL/TLS certificates will be free by Q2 2015. Get the certificate here: https://letsencrypt.org/ Let's Encrypt will offer domain-validated certificates signed through IdenTrust at no charge. When this goes live, these questions should be closed, IMHO


10

What could be other good advices, to achieve as much security as I can without using SSL? You can use TLS instead of doing anything stupid.


10

What you are trying to do is impossible without a secure way of sending your files to the client, such as TLS. Your approaches of hashing the password client-side require the javascript to be securely sent to the client. Otherwise, a MITM could simply serve a script that does not hash the password, but instead send the clear text password directly to them. ...


4

You're using the wrong approach to prevent SQL injection. Sanitizing inputs can help provide security, but by far the best way to avoid SQL injection is to remove the thing that allowed it in the first place: mixing code and (user-supplied) data in the same string, such that the database doesn't know what was supposed to be code and what was supposed to be ...


4

unserialize allows the creation of arbitrary object constructs of any class with arbitrary attributes. During deserialization, the lifetime of an object, and the interaction with the object, several methods including magic methods may get called using these arbitrarily definable attributes. An attacker may be able to utilize the functionality provided within ...


3

Hashing is a one-way function. Encryption can be reversed with a key; hashes cannot. The only time you'd use hashing is if you don't care what the value of something is, you just want to check that it's equal to what the user just typed in. In particular, if you hash the email addresses, you will never be able to send mail to the addresses. Since you want to ...


3

The only way to be secure without TLS is a browser plugin, which needs to be downloaded... over TLS. And a browser plugin is a huge usability drawback. The reason for this is there needs to be some trusted code on the user's computer. This can be either the TLS code in the user's browser, or the plugin code.


2

If your only concern is Code Execution, yes, you are safe. But like you said, you are vulnerable to Cross Site Scripting. And depends on the purpose of your page, you could be vulnerable to IP leak and token stealing.


2

That's called a "keyed hash" and the key is sometimes called "pepper." Yes, there is a security advantage. If the key is not stored in a database but is, perhaps, a constant in a program, then a database leak through SQL injection or similar will not reveal the key and your data will be nearly crack-proof. Of course, if the OS gets owned, it sort-of ...


2

Your scheme is problematic from a UX and Security standpoint. Bad UX, If implemented properly a user who logs in on their phone will immediately be logged out on their computer, or whatever. There are several other problematic cases where users who shouldn't be logged out are logged out. That's not horrible, but depending on the use of your application is ...


2

I am considering always passing ?PHPSESSID=x in the query string for each relevant url as a workaround. This is not the best practice, but if you decide to choose this method (because it is easy), you can make something like this: <?php define("COOKIE_NAME", "PHPSESSID"); define("DOMAIN", "example.com"); function ...


1

No. I'm not a PHP developer, but I found this on the uniqID function you're using: UniqID manual page Warning This function does not create random nor unpredictable strings. This function must not be used for security purposes. Use a cryptographically secure random function/generator and cryptographically secure hash functions to create unpredictable ...


1

I would say no. Here is an interesting article on a similar topic. I would suggest: Using a hash function (this does not add virtually any security on its own, but makes improvements mentioned below much more efficient), e.g. $csrfToken = base64_encode(hash("sha256", uniqid(mt_rand(100, 999) . microtime(), true), true)); Adding a long, random secret ...


1

Just to confuse you further... IMHO filter_input() is a very bad solution to a dangerous problem. It doesn't just filter input, it frequently transforms it as well. And you should never transform input. By the time the data is available to PHP, then it is too late to fix anything which might be toxic to PHP. Whenever data leaves PHP then it should be ...


1

Unless the company tells you that they have been audited by some security company (and depending on the company that assessed it), you will never know until you take a look for yourself. Trust is a complicate thing... It is hard to gain and very easy to be left along the way. One think that you may do is talk to Agriya and tell them that you're interested ...


1

As mentioned above, your choice of cryptographic primitive is going to depend on what you want to do with it. For password storage, you are going to want to use a hashing algorithm. A hash is a one-way operation which will give you a unique, deterministic output for a given input, but it is impossible to reverse the operation. For example, if I use the ...


1

With your current code, users can call any function with zero parameters with starts with func. Although there are probably none in the PHP standard repertoire that may pose a threat when being called, the runtime environment you want to use this in may have such functions. You may also want to change the prefix or composition of the actual function name in ...


1

You do not sanitize your user input, that by itself is considered bad practise. Although I don't think it can be exploited, perhaps the following code is considered more secure. <?php function x() { // what ever this function should do } function y() { // what ever this function should do } ...


1

The "mathematical proof" is you can choose N arbitrarily: t(bcrypt) * (2^N) >> t(sha) The final hash is all about avoiding collisions, so you're safe so long as hash >> password The salt is all about avoiding rainbow tables, so you're safe so long as (rainbow table size) * (salt) >> (attacker storage space)


1

By controlling the presentation layer, you may display a confirmation pop-up before redirecting to the target URLs. While requesting confirmation, the pop-up would highlight the target domain and include a reminder about dangers related to malicious websites


1

This information is only relevant for older (unsupported) versions of PHP. Null byte injection has been fixed in PHP 5.3.4 (which it's self is already an old and unsupported PHP version): https://bugs.php.net/bug.php?id=39863.


1

Text comments can be included in PNG, JPG, and GIF files. No steganography is necessary. As you have discovered, if the image is included (using PHP's include construct) the code will be executed. That works because PHP has copy mode and interpret mode. Included files start in copy mode, so the PHP interpreter is not looking at the bits of the image at ...


1

I bet there's a small piece of code hidden somewhere that takes care of deobfuscating the real payload from the image and then executing it; that allows the attackers to have a very small piece of malware that they can easily hide somewhere in an otherwise unoffensive PHP file, while keeping the big and not-so-sneaky malware in an image which allows it to go ...


1

You are correct. If the ultimate goal is to process the file on the server, then renaming it provides a layer of protection. However, if you are going to redisplay the file, then renaming it hasn't helped; the attacker just uses whatever redisplay mechanism your site provides. Let us suppose that your web users can upload pictures that are then displayed ...


1

The other answers are clear - use SSL however, to point out what would fail if you implemented it as described: I thought of solving it with a first hashing on client side with JavaScript and then on the server side, if I receive hashed values(in case someone deletes some JavaScript), a second hashing and store those hashed values in the user ...



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