News Feed
Jobs Feed
Sections




News Archive
feed this:

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

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


Developer Drive Blog:
How to Prevent a SQL Injection Attack
October 14, 2011 @ 09:25:12

From the Developer Drive blog there's a recent post with some suggestions on how you can help to prevent SQL injections in your PHP application and make it that much harder for would-be attackers to do what they shouldn't.

Why do SQL injections happen so often? The shortest answer is that SQL injections are so popular because of poor programming. Hackers know about the potential of a successful SQL injection attack and they search for vulnerabilities. Unfortunately, very often they don't have to search hard - vulnerabilities pop right in their face. [...] The good news is that fortunately, SQL injections are also relatively easy to prevent.

They list nine easy things you can do to help prevent the attacks:

  • Patch your SQL server regularly
  • Limit the use of dynamic queries
  • Escape user input
  • Store database credentials in a separate file
  • Use the principle of least privilege
  • Turn magic quotes off
  • Disable shells
  • Disable any other DB functionality you don't need
  • Test your code
0 comments voice your opinion now!
sqlinjection security sql prevent tips attack


Artur Ejsmont's Blog:
HTTP response splitting and mail headers splitting attacks
November 15, 2010 @ 10:57:16

In a recent post to his blog Artur Ejsmont looks at an attack that could potentially leave a hole open in your PHP-based application for a cross-site scripting (XSS) attack - HTTP response splitting (mail headers too).

There are two similar security issues both taken care of by Suhosin patch and strict escaping/encoding rules. They both relate to injecting new lines into headers of network protocols. They are not very well known and i think its worth mentioning it. HTTP response splitting is a web based attack where hacker manages to trick the server into injecting new lines into response headers along with arbitrary code. If you use GET/POST parameters in the headers like cookie or location, then someone could provide new lines with XSS attack.

He gives some examples of how it might work via the header function so that superglobals might be abused (like adding information on the URL to inject into $_GET). To prevent the attack, you just have to ensure that no special characters make it into the headers or cookies. He also mentions that the Suhosin patch takes care of the issue automatically.

2 comments voice your opinion now!
http response header split example attack



Community Events











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


unittest component podcast composer dependency security package application install framework introduction opinion facebook code series release symfony2 hack language hhvm

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