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.

In this recent post to his site Greg Freeman share some things to check for when you think your PHP site (any kind, even something like WordPress) might have been compromised.

A friend of mine recently had their site compromised, they were running an older version of IP.Board that is vulnerable to a local file inclusion vulnerability. This post won’t be about IP.Board or any specific php code, it will show you how to locate potential malicious php code hosted on your servers and how to fix it. Finally I will give a brief explanation on what attacker’s are uploading to compromised sites.

Among the things he recommends are tips like:

• Check your Access Logs
• Finding Recently Modified PHP Files
• Finding obfuscated code
• Always search your writable upload directories for executable code
• Check .htaccess Files if you use Apache

You can find the descriptions for each of these (and some others to watch out for) in the full post.

As Ars Technica reports, there was a recent exploit found on the SourceForce website's installation of phpMyAdmin that allowed an attacker to POST anything to the site to be executed.

Developers of phpMyAdmin warned users they may be running a malicious version of the open-source software package after discovering backdoor code was snuck into a package being distributed over the widely used SourceForge repository. The backdoor contains code that allows remote attackers to take control of the underlying server running the modified phpMyAdmin, which is a Web-based tool for managing MySQL databases. The PHP script is found in a file named server_sync.php, and it reads PHP code embedded in standard POST Web requests and then executes it. T

The backdoor was somehow snuck into the code of phpMyAdmin on one of the mirrors and distributed to those downloading version 3.5.2.2. They think that the only downloads that were tainted with this issue were on the "cdnetworks" mirror site. You can find out more about the issue in this advisory - be sure you check your installation for a "server_sync.php" file and remove it if it exists.

Sameer Borate, in the wake of having security issues with his site, has posted a hint you could use to help detect when something has changed in important files in your application by checking their hash.

Today a couple of hours back my site got compromised. Not much changes to the code, but the .htacces was changed and some code [...] was added to the .htaccess file, which redirected the traffic coming from search engines to a malware site. It has now been removed and to prevent any such changes to the .htaccess file in the future, I’ve written a small php script that compares the hash (SHA1) of the two major files that usually get compromised and compare them to the one originally stored.

It's not a preventative measure by any means, but it can help you keep track of if something's changed. Several issues have popped up in the major blogging engines that allow for changes to be made directly to files. These changes result in the sha hash to be different and can be used to trigger a security alert. His sample code shows a basic call to mail an alert, but it could be as complex as you'd like (possibly even logging to a database or the like).

Chris Jones has a new post to his OTN blog today pointing to two new articles by Eli White about managing malicious website use:

The techniques Eli covers will always be applicable in one form or another. They should be a fundamental part of any website architect's bag of tricks.

The first article focuses more on methods for preventing and dealing with the inevitable spamming that comes with running a larger site. Eli's experience at Digg has provided him with recommendations like creating hurdles for spammers to get past and evaluating the content (services like Defensio or Akismet are useful for this).

The second article talks about something a bit harder to deal with - when users "game the system" and find the loopholes. His recommendations to combat this sort of abuse include rate limiting, pattern matching and leaving "traps" by tracking user usage.