For the past 18 months working with PHP, i've primarily used alternatives, not out of preference, but because netbeans xdebug integration consistently failed me. It would (might) work with a remote apache, but would not play with scripts executed remotely from the command line. I could be fairly sure my xdebug config was sound as I no problems with MacGDB and PHPStorm whatsoever.

With a little more investigation, he discovered that it was the OSX firewall causing issues. He found that, with a new incoming connection came a confirmation box to approve the connection. This, of course, wasn't passed along to Netbeans so he never saw it. In the end, he set up a reverse SSH tunnel to bypass the firewall completely (command included).

The PHP debugging extension Xdebug has "remote" debugging capabilities for single-step debugging PHP applications. This works by setting your favourite IDE into listening mode and instructing Xdebug (with one of the handy browser extensions for example) to initiate debugging. [...] There could however be a firewall in the way that prevents Xdebug connecting directly to your IDE's IP address. That can be because the network you are on employs NAT. [...] In this case, there is no way Xdebug can connect to your IDE's IP address and port. Or is there?

His alternative requires SSH access to the remote machine - building a tunnel from your local machine to the remote server XDebug can use to get around the firewall. He explains the shell command to set up the tunnel and, a more graphical way, through the Putty ssh/telnet client. A quick call to "netstat" can tell you if things are working correctly or not. All that's left then is to point your XDebug to the port on the localhost and you should be good to go on debugging.

ModSecurity is a web application firewall. It can live in and out of the Apache web server environment, one of the most popular web servers around. ModSecurity is infinitely customizable and extremely powerful. The philosophy of ModSecurity can be summed up in a few words. Look, and only modify if I tell you to.

The author of the post (Orlanao Medina) thinks that this book is *the* resource for ModSecurity-related information, providing step-by-step information on how to work with the tool both inside and outside of Apache. It shares tips on blocking XSS attacks, brute force attacks and generally protecting your application in general.

Being an efficient developer often means abstracting functionality such that a single function can be applied to a variety of uses across an application. Even as this decreases risk of errors, time to develop, and the attack surface necessary to secure the application it also makes implementing security more difficult.

The article talks about a project the author was working on and how, when he came across a need for a component and found one that worked, they were surprised to see how difficult it would be to secure it without adding on extra code bloat. He describes some of the issue and talks about how the development of the component must not have included any thought into things like input validation or filtering. One suggestion is to employ a firewall to sit in front of the entire application and handle all of these things without changes to the code.

Everyone knows that you should filter your inputs most of the good programmers do it but when you are working with a large team of programmers on an open source project things slip up, errors do creep in, at times like this you wish for a mechanism which would prevent your team from making such mistakes, some thing which forces them to declare their intent.

One solution he mentions is the input_filter extension for PHP5, but this doesn't help most users since it's normally off by default and PHP5-only. The other solution, Inspekt, a modified version of the Zend_Filter_input component of the Zend Framework. An example is included and a list of filtering methods is too (like getAlnum, getDigits and getInt).

The most secure application is one with no connection to the outside world.

As we've covered, you can't really disconnect the network from your web server if you are building web applications. You can however, carefully consider which servers need to be connected to the outside world and which can be inside your firewall. Beyond that, you can also evaluate how those servers that have to remain outside your firewall communicate with the ones inside.

No, his suggestion is not to take your application "off the grip" but more to limit access to things like database servers to help protect the data that lives inside it.