Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Pádraic Brady:
PHP’s “Magic Hash” Vulnerability (Or Beware Of Type Juggling)
May 14, 2015 @ 12:19:43

Pádraic Brady has a new post to his site talking about the recently announced (but actually relatively old) issue with PHP hash comparison, the "magic hash" issues.

A while back, I noticed a flurry of activity around a somewhat obvious outcome of PHP’s type juggling antics. As the snowball gathered pace and grew, it’s being more widely reported as a vulnerability dubbed “Magic Hashes”. What is this mysterious potential vulnerability in PHP applications? The vulnerability is a straightforward outcome of PHP’s type juggling antics.

He talks about the == (double equals) versus === (triple equals), how they differ and how the use of the triple equals basically negates this issue. The problem comes back around to PHP's type juggling and how it assumes equality based on the data given. He includes some specific examples showing places the issue can happen even when comparing two variables of the same type. He also makes a mention of another issue that can come in separate from this called timing attacks and how to prevent them as well.

tagged: magichash vulnerability typejuggling timing attack doubleequals tripleequals

Link: http://blog.astrumfutura.com/2015/05/phps-magic-hash-vulnerability-or-beware-of-type-juggling/

Anthony Ferrara:
It's All About Time
Dec 01, 2014 @ 10:46:15

In his latest post Anthony Ferrara talks about a tricky subject in PHP - timing attacks. A timing attack has to do with vulnerabilities that can come up because of the differences in time it takes to perform cryptographic operations (like hashing or encrypting).

An interesting pull request has been opened against PHP to make bin2hex() constant time. This has lead to some interesting discussion on the mailing list (which even got me to reply :-X). There has been pretty good coverage over remote timing attacks in PHP, but they talk about string comparison. I'd like to talk about other types of timing attacks.

He starts with a definition of what a remote timing attack is and provides an example of a simple script showing the delay that's key to the attack. His script deals with string location but it gives you an idea of how the attack works and where the danger lies. He points out that even remotely attackers could determine the times to perform operations (down to the nanosecond) and use this to their advantage. He points out that both == and === are vulnerable to this type of attack because of how the comparison happens. He gives two options (one an internal function) to help protect your application and briefly covers a few other types of timing attacks: index lookup, cache-timing and branch-based timing attacks.

tagged: timing attack comparison time example tutorial introduction prevent

Link: http://blog.ircmaxell.com/2014/11/its-all-about-time.html

Anna Filina:
Brute-force countermeasures
Jun 11, 2014 @ 10:09:10

In her latest post Anna Filina has made some recommendations of countermeasures you can use to help prevent abuse against brute force attacks in your applications. The recommendations aren't PHP-specific, but they're a good guide and a place to start.

Password brute-forcing refers to trying all password permutations until the attacker finds the right one. Here are some of the most common ways to mitigate that risk: increase the length of the password and increase the number of possible characters. [...] The human factor should not be ignored here. People often use letters in the beginning and numbers at the end.

She recommends a few other tactics to helping prevent the brute forcing including locking an account after a number of unsuccessful login attempts and requiring a CAPTCHA after a number of unsuccessful logins. She recommends not relying on a single method to help prevent this kind of attack, however. Multiple layers can only help, but be careful not to introduce too much complexity.

tagged: brute force attack countermeasure password

Link: http://afilina.com/brute-force-countermesures

Is Your OAuth 2.0 Application Secure?
May 26, 2014 @ 11:29:39

The PHPClasses.org blog has a new post highlighting a vulnerability in the OAuth 2.0 specification that's been talked about quite a bit lately, the Covert Redirect Vulnerability. This issue allows potential attackers to trick users into redirecting to malicious sites and possibly gain access to personal information.

This vulnerability affects applications that implement protocols like OAuth 2.0 and OpenID. Lets see how this affects an OAuth 2.0 application. [...] The way it works is that your application redirects to a specific page of the Facebook site. There the user is asked if he wants to give your application permission to access Facebook API on his behalf. After the user agrees, his browser is redirected back to your site to a URL that your application specified called redirect_uri. From then on your site completes the process to get a special access token string that will be used by your site to access Facebook API on behalf of the user.

This token represents the user and can then be used to access the user's account. If that token fell into the wrong hands, they could access data they shouldn't. He includes a diagram of the flow and a link to a video explaining the problem in a bit more depth. He recommends three ways to help prevent this issue and what to look for in your implementation that could leave you vulnerable.

tagged: oauth2 security redirect uri malicious attack

Link: http://www.phpclasses.org/blog/package/7700/post/4-Is-Your-OAuth-20-Application-Secure.html

Composer still susceptible to remote code execution via MITM
Oct 03, 2013 @ 11:26:15

In this recent post to Reddit.com, a point is brought up about the popular PHP package manager, Composer about it being susceptible to a common attack called the "Man in the Middle". This issue on the project's Github repository talks more about it:

Composer runs code from HTTP sources without validating the source of the download or the code downloaded. As such, trivial man-in-the-middle attacks through any number of vectors (dns, networking, local server exploit, etc) will result in execution of code of an attackers choosing at the userlevel of the user running composer. (Typically a developer account)

Replace getcomposer.org for a given network perspective by replacing it with a malicious http instance (eg by changing the DNS locally, at the lan, at an isp or hosting provider dns resolver, or globally or equally easily by replacing a route to the legitimate server (eg arpspoof)) . The http server instance is configured to serve a malicious /composer.phar and a /version url that produces random data. When users run self-update, the malicious code will be downloaded and run as the user that is executing the self-update command.

As of yet some patches and ideas have been proposed to correct this issue, but it hasn't been resolved and is currently listed as a "blocker" on the project. One suggestion, signing packages, seems to be the front-runner in the current discussion, something that package managers for other languages have already implemented (like npm for Node.js and pip for Python).

tagged: composer package manager remote code execution attack maninthemiddle mitm

Link: http://www.reddit.com/r/PHP/comments/1nkmw8/composer_still_susceptible_to_remote_code/

Anthony Ferrara:
Preventing CSRF Attacks
Feb 20, 2013 @ 09:36:41

Anthony Ferrara has written up a new post to his site looking at efective use of CSRF tokens and a few different strategies for generating them.

There's been a bit of noise in the past week about the proper way to prevent Cross-Site-Request-Forgery (CSRF) attacks. It seemed to have started with this post. There's been discussion in the comments, and on Twitter about it, and there seems to be several opposing viewpoints on the matter. I want to start off by saying that I agree completely with the post in question. But I figured I'd write a post to explain WHY I agree with it.

He starts with an overview of a few of the common types of request forgery including from a javascript injection, a Man-in-the-Middle attack and a replay attack. He then breaks up the "lines of defense" part of the post into three different sections - adding a hidden token field to forms, changing the token for each request and using random numbers when regenrating them.

tagged: csrf attack prevention overview token generation tutorial


Hackers Compromise PHP Sites to Launch Attacks
Dec 18, 2012 @ 12:07:35

According to this new post on DevShed, there have been several targeted attacks against U.S. bank websites (DDoS), some of which involved the compromise of PHP-based applications.

Once the hackers got into the PHP-based websites, they inserted toolkits to turn them into launch pads for their distributed denial-of-service attacks. Hackers then launched the attacks on banks by connecting directly to the compromised PHP-based websites and sending them commands, or took advantage of intermediate servers, proxies or scripts to make the websites do their bidding. InformationWeek lists three attack tools used by the hackers: KamiKaze, AMOS, and the “itsokaynoproblembro” toolkit, also known as Brobot.

Several major banks have been targeted including Bank of America, JP Morgan/Chase, HSBC and Well Fargo. The main problem was out-of-date software running on the site containing known security issues the attackers could exploit to install their own software.

If a hacker can break into a PHP-based website to use it as a staging area for an attack on a different website, they can also use that website to store stolen information. InformationWeek cited the example of the Eurograbber attack campaign, revealed earlier this month. The gang involved in that campaign stole $47 million from more than 30,000 corporate and private banking customers – and used PHP-based websites into which they hacked to store stolen information.
tagged: hacker bank website exploit attack timthumb joomla wordpress


Anson Cheung:
Top 6 security attacks in PHP
Aug 09, 2012 @ 17:03:55

Anson Cheung has posted about some security attacks (six of them) that you need to watch out for when developing your apps.

Be aware of the most common security threats to PHP applications is the important step to secure your PHP scripts may not be immune. Here, the article is going to go over top 6 common security threads in PHP scripts. You may familiar with this, if not, this is a good time for you to read and keep in mind.

The top six on his list are:

  • SQL Injection
  • Cross-Site Scripting (XSS)
  • Session fixation
  • Session capturing/hijacking
  • Cross-Site Request Forgeries (CSRF)
  • Code Injection

For each item, he includes a bit of explanation as to what the issue is and a common solution as to how to prevent it.

tagged: security attack xss csrf session sqlinjection code


Protecting against attack?
May 18, 2012 @ 10:19:35

In this recent post to Reddit.com, the question of application security is asked - the poster wants recommendations on how he should keep his app safe from would-be attackers:

I can code fairly well in PHP these days, but my security isn't so hot. Is there a tutorial or plugin you guys can recommend as to how I should be protecting my php pages/inputs? I want to avoid common attacks like XSS, inputs with NULL or DROP TABLE etc?

Responses on the post include recommendations related to:

  • Using the Chorizo scanner to find common issues in your code
  • Using PDO for database connections (with bound parameters)
  • Not trusting "$_SERVER"
  • Data sanitization

There's also links to a few other resources with more details.

tagged: security attack opinion xss pdo validate filter


PHP 5.4.3 and PHP 5.3.13 Released!
May 09, 2012 @ 07:10:36

The PHP project has released another update to both the 5.3.x and 5.4 revisions of the language correcting the bug that was found dealing with a flaw in CGI-based setups.

The PHP development team would like to announce the immediate availability of PHP 5.4.3 and PHP 5.3.13. All users are encouraged to upgrade to PHP 5.4.3 or PHP 5.3.13 The releases complete a fix for a vulnerability in CGI-based setups (CVE-2012-2311). Note: mod_php and php-fpm are not vulnerable to this attack. PHP 5.4.3 fixes a buffer overflow vulnerability in the apache_request_headers() (CVE-2012-2329). The PHP 5.3 series is not vulnerable to this issue.

Users are encouraged to upgrade their applications, especially those using CGI-based setups. You can find the latest source on the downloads page and the Windows binaries on windows.php.net.

tagged: release bugfix cgi apache vulnerability attack