News Feed
Sections




News Archive
feed this:

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

Anna Filina:
Brute-force countermeasures
June 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.

0 comments voice your opinion now!
brute force attack countermeasure password

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

PHPClasses.org:
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.

0 comments voice your opinion now!
oauth2 security redirect uri malicious attack

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

Reddit.com:
Composer still susceptible to remote code execution via MITM
October 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).

0 comments voice your opinion now!
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
February 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.

0 comments voice your opinion now!
csrf attack prevention overview token generation tutorial


DevShed:
Hackers Compromise PHP Sites to Launch Attacks
December 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.
0 comments voice your opinion now!
hacker bank website exploit attack timthumb joomla wordpress


Anson Cheung:
Top 6 security attacks in PHP
August 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.

0 comments voice your opinion now!
security attack xss csrf session sqlinjection code


Reddit.com:
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.

0 comments voice your opinion now!
security attack opinion xss pdo validate filter


PHP.net:
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.

0 comments voice your opinion now!
release bugfix cgi apache vulnerability attack


Paul Reinheimer's Blog:
Cookies don't replace Sessions
January 24, 2012 @ 09:26:20

In a new post to his blog Paul Reinheimer talks about replacing sessions with cookies and some of the (security) pitfalls that can come with it.

I've seen several instances where people have demonstrated the ease with which encrypted cookies can replace sessions within PHP. Michael Nitschinger wrote a piece recently demonstrating the switch with Lithium, while CodeIgniter does this by default (optionally encrypting). The problem is that while replacing sessions with cookies works, it introduces a few risks not present with native session support, and these risks tend to be under documented.

He gives an illustration of an attacker who sits between Amazon and one of their warehouses. Despite encrypting their order details, all it would take is the attacker to grab an order and copy it and resend (a "replay attack"). He's created an example application to illustrate the point (source on github). The attacker doesn't even have to know what the encrypted information contains - they only have to replicate it.

0 comments voice your opinion now!
cookies session cryptography advice security replay attack


Freek Lijten's Blog:
The real problem of the hash table dos attack
December 30, 2011 @ 12:53:35

In response to some of the comments being made about the hash table Denial of Service attack recently posted Freek Lijten has posted his thoughts about the real problem with the whole situation - how it was handled by the communities involved.

Interesting they may be, but I want to address what in my opinion is the real problem: The way the communication around it was handled by different projects and the fact that the exploit could still exist at all. [...] In the presentation Wälde and Klink talk about their disclosure process. The PHP project had them wait 3 weeks for a first response while this is obviously a serious matter.

He argues that things like a commit message mentioning a DoS prevention fix instead of just mentioning the fix have the potential to do more harm than good. He also points out that other communities were notified of the problem (like Python) and some still haven't responded to the issue.

This attack was the result of good research and it is important that it is disclosed. More importantly however is the fact that organisation got by with years of not noticing it and even worse, reacted very poor after being informed. I can't say I have a ready solution to avoid these kind of things in the future, perhaps that will prove to be an interesting discussion.
0 comments voice your opinion now!
dos attack hash table opinion community response



Community Events





Don't see your event here?
Let us know!


symfony update introduction release community interview unittest library install framework podcast zendserver deployment opinion laravel tips language api series package

All content copyright, 2014 PHPDeveloper.org :: info@phpdeveloper.org - Powered by the Solar PHP Framework