Tag Info

New answers tagged

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)


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 ...


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

Well, so you could do the asymmetric key method, but if you think about it, the reason the password is encrypted on the client, is usually the same password is used in other instances, so if you use a separate password for transactions with this api, you'll isolate problems only to this method of access.


0

If you can't change the API, then you need to either store the password or ask for it from the user every time you need to make an API call. Assuming that asking isn't practical, store the password encrypted. No, it won't stop a serious attacker, but it's better than nothing: storing the password in plaintext won't even stop a script kiddie.


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 ...


0

this is simple. first set the session cookie's HttpOnly use TLS ssl, meaning you have everything encrypted and modifications are detected set cookie.secure prevent any XSS, sql injection, or any other injection then you should generate new session at every login and invalidate old sessions that should be all against session hijacking


-3

best way is following some tutorial http://www.wikihow.com/Create-a-Secure-Session-Managment-System-in-PHP-and-MySQL for safely destroy session_unset(); session_destroy();


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


0

Answer for the first part: The php version of OWASP CSRF Guard has been implemented as OWASP CSRF Protector (Project name was changed due to diffrenece in design logic). Its available on github for download!


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 ...


0

As this is a remote file include vulnerability you do not need to rely on null byte injection, simply serve the malicious code with a .gif extension like this: http://www.example.com/badcode.php.gif


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.


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 ...


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 ...


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 ...


0

It's bad practice. Whenever you can, reuse what already exist instead of creating your own. Session management is pretty common and just work. Since the usual session cookie will most likely be blocked as a third party cookie I am trying to find a suitable way to do this. No, the cookie will not be blocked in your iframe. Cookie are set browser wide ...


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.


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 ...


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. ...


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 ...


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.


1

There's a ton of ink written on the subject of why you shouldn't try doing your own homebrew filters for these things! Please have a look at OWASP's XSS mitigation guidelines. Use the proper libraries for these things - OWASP ESAPI for PHP is a great tool to start with. I'd look at HTML Purifier as well.


17

I'm generally a fan of not re inventing the wheel because people way smarter than us already did. I did a quick search for you and found the current library you can use: https://code.google.com/p/php-antixss/ Re: your code, it looks a little too simple to prevent fully. I would use a standardized solution that is used by others and continuously contributed ...


6

No, it is not. Try insert javascript&colon;alert(9) as the URL, or like @wireghoul pointed, JAVASCRIPT:alert(9). Even with javascript :alert(9) in older browsers (IE < 8, I guess). Better solution: <?php header('Content-Type: text/html; charset=utf-8'); header('X-Content-Type-Options: nosniff'); $site = $_GET["url"]; $site_lowercase = ...


1

You might need to re-read the advisory, the important part is this: A text containing carefully mixed square and angle brackets confuses the splitting process and results in HTML code getting partially texturized. An attacker can exploit the bug to supply any attributes in the allowed HTML tags. A style attribute can be used to create a ...


3

I have actually seen this little bit of code (or something very similar) infecting a system before. At a high level this code tries to watch for traffic which meets certain criteria (Bot stats, source, keywords in request, etc.) and dumps what can only be described as something between a black hat SEO list of keywords and an advertisement onto the top of ...


1

If authenticated properly, curl should retrieve the rendered page. Here's an example in PHP to retrieve a (rendered) page: // Get cURL resource $curl = curl_init(); // Set some options - we are passing in a useragent too here curl_setopt_array($curl, array( CURLOPT_RETURNTRANSFER => 1, CURLOPT_URL => "example.com/user?privacyemail.php", ...


0

By trial and error I found the answer: It seems that when SSL is used (test 2), setcookie is required as follows: setcookie('sessionname', session_id(), time()+whatever, '/', 'theSSLhostaddress', true, true or false); Also, the htaccess works in test 2. The non-SSL script (test 1) did not require setcookie! Hope this helps.


1

It looks like it was a private disclosure, so it seems that we will not know this for sure unless someone takes the time to analyze the framework code (or @chrismsnz decides to explain it to us). But from what i could tell, it seems like Session::token() returns a string and Input::get() returns a mixed object. By the rather short explanation they gave, ...



Top 50 recent answers are included