Slashdot Mirror

a 'security' guy

You know this guy is Samy Kamkar, the hacker who also unleashed the first-ever XSS worm on the world that infected a million MySpace profiles in a matter of hours...

Tomorrow I happen to attend a meeting of OWASP where Samy will speak about the latest XSS exploits, other JavaScript tricks, and other things (like a nice new method of NAT penetration)... I could say the title 'security guy' is earned by him for finding some great hacks and sharing them with the world, and even taking time to talk about it in person to the open source community.

but most of all, Samy is my hero

Stop posting. Start reading.

http://www.owasp.org/index.php/Cross-site_Scripting_(XSS)

Here are a few pointers, mostly around PHP web app security:

- http://www.owasp.org/ - the Open Web Application Security Project has a comprehensive list of things to cover - see their http://www.owasp.org/index.php/PHP_Top_5 (top 5 PHP issues) in particular

- http://www.sitepoint.com/article/php-security-blunders/ Top 7 PHP security blunders - use =htmlspecialchars= for output of variables to page and do MySQL string escaping

- http://www.phpbuilder.com/columns/ian_gilfillan20050707.php3 - ensure include files can't be reached directly from HTTP.

- http://it.slashdot.org/comments.pl?sid=1121901&cid=26797895 - use http://us2.php.net/manual/en/function.filter-var.php -PHP Filter features]] (only in PHP 5.2.0 onwards)

- http://sucuri.net/ - monitors your site for free to detect compromises that affect readable pages

Final point: don't "filter out" dangerous characters, this is never ending and can never be done - instead, for any given parameter or input field, define the valid characters (e.g. alphanumeric, date, etc) and specifically allow ONLY those characters. This 'filtering in' approach is far safer.

Here are a few pointers, mostly around PHP web app security:

- http://www.owasp.org/ - the Open Web Application Security Project has a comprehensive list of things to cover - see their http://www.owasp.org/index.php/PHP_Top_5 (top 5 PHP issues) in particular

- http://www.sitepoint.com/article/php-security-blunders/ Top 7 PHP security blunders - use =htmlspecialchars= for output of variables to page and do MySQL string escaping

- http://www.phpbuilder.com/columns/ian_gilfillan20050707.php3 - ensure include files can't be reached directly from HTTP.

- http://it.slashdot.org/comments.pl?sid=1121901&cid=26797895 - use http://us2.php.net/manual/en/function.filter-var.php -PHP Filter features]] (only in PHP 5.2.0 onwards)

- http://sucuri.net/ - monitors your site for free to detect compromises that affect readable pages

Final point: don't "filter out" dangerous characters, this is never ending and can never be done - instead, for any given parameter or input field, define the valid characters (e.g. alphanumeric, date, etc) and specifically allow ONLY those characters. This 'filtering in' approach is far safer.

Check out the OWASP site for a good introduction to web security topics/techniques. There is plenty of information across the site to give you a start on what you should be doing.

You'll want to look at implementing things like:

• CSRF tokens (including use of a strong PRNG for generating nonces where you're *not* leaking the internal state of the PRNG at any point of time - example)
• X-Frame-Options (prevents clickjacking)
• X-Content-Security-Policy (prevents clickjacking and XSS bugs)
• HttpOnly (cookie flag for extra XSS protection)
• Use of common code in your game for creating sanitised SQL queries, outputting sanitised strings, etc.

Use the OWASP Application Verification Standard - this gives you an insight to the controls you need to work on first. A game should be at Level 2B.

http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project

Don't worry about the language snobs - ANY language and ANY framework can be secured as long as you do the right thing in terms of design. Where you can go wrong is trusting untrustable data - such as that obtained from the browser without first canonicalizing, validating and ensuring that it meets business logic requirements (such as not being able to pass through walls, or avoiding object collision algorithms, asset or stat manipulation, or score manipulation. The client is completely untrustworthy, and you should be writing your code with that in mind 100% of the time.

I lean towards publishing the code. The only secrets you really need to protect are master authentication tokens in (say) config.php and authorization tokens in flight. So don't publish the master config.php secrets in SVN or similar, but everything else should be completely open.

You got me before my morning (afternoon) coffee so here are some haphazard thoughts:

1) You're writing a PHP/MySQL app. It doesn't matter if it's a game or the next big social networking site. There are holes common to all web apps (check out the OWASP Top 10). There are also holes common in PHP code, such as remote file inclusion. There are things you can do wrong with JavaScript. Learn about them, learn about how to prevent them and write your code accordingly. Security should be part of development, not something you tack on afterward. This means using good coding convention (i.e using parametrized queries instead of concatenation, always encoding output, etc) and ensuring that any design decision you make does not compromise the security of your application. Make sure security is multi-layered as well. For example, even if you think your app is 100% free of SQL injection (wrong assumption!), you still need to make sure you've properly hashed user passwords in the database in case they're exposed. (Side note: please don't use MD5 for this; look into bcrypt, or at least many rounds of SHA-256 or such.)

2) Harden your environment. No amount of hardening will stop all attacks, but it may help mitigate their impact, and if you're lucky, it may thwart some script kiddies or automated scripts. Running PHP? Harden the crap out of your php.ini (magic_quotes_gpc, turn off fopen() for URLs, etc). Think about installing the Suhosin patch. Just don't get complacent; there are ways around all these protections and they are not a substitute for secure code! You may also consider a web-app firewall (WAF), in the vein of mod_security, but don't fully rely on these either. If you're publishing code for others to use, don't ever count on your users to implement these same protections in their environment.

3) Web app scanners can help, especially if you're a novice with security, but once again, they will not catch everything (probably not even a lot of things.) There's skipfish, NetSparker and free versions of some of the more commercial scanners.

4) I know your question was whether to publish your code. I say "Yes", but this is a personal opinion -- I just happen to think it will give security dudes more of a chance to audit your code, and attackers will find your vulnerabilities anyway, through poking at your app and fuzzing even if nothing is published.

I hope that helps a little!

Another way to prevent SQL injection attacks is to use a Web application firewall. The advantage to using an application firewall is that it solves the problem without having to verify every one of the (possibly many) scripts running on the server.

http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

How many times do we need to say the same thing before people start listening?

Nice cheat sheet but I was a bit surprised to see "* Also Enforce: Least Privilege" listed under "Additional Defenses". Perhaps it is just my opinion but it seems least privilege should be very high on the list as has the potential to negate many application code and query instances where a developer may make a mistake or is simply lax in their methods.

When I had a PHPBB website hit by an SQL Injection attack I not only stopped using PHPBB but I started an open source project with the idea of creating components to be used in the design of a database backed web application that could rely on the least privilege principle at the database engine rather than having absolute faith in the web application code itself to enforce security.

It is not a perfect solution but it has the potential to stop many SQL injection attacks even in cases where the web application has some bad code.

http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

How many times do we need to say the same thing before people start listening? Oh, that's why we still have STDs. Because people don't take basic steps to reduce risk by orders of magnitude.

Interested parties should also be aware of web goat by the owasp team. http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project

You still need bind variables mentioned by the gp if using HQL.
http://www.owasp.org/index.php/Interpreter_Injection#ORM_Injection

Ah, the ol' Reject-Known-Bad or Sanitise-All-Input paradigm. It is indeed impossible to anticipate all the bone-headed ways in which input can be botched, maliciously or not. Thus, it is then more secure to prepare a discreet list of valid input and only accept that, rejecting anything that does not conform to what you expect. This rejection is not based on a black-list of bad input to compare against, but on a sort of white-list what you assert your program can handle.

If you would have considered this approach, your application would have rejected the message with duplicate images (perhaps logging this reaction somewhere for you to review later), and continued churning along without crashing. (Alternatively, you could have modeled your application on the Real World and realized that messages may contain, and often do, the same image more than once and expected that; but I understand that problem analysis is not very common these days.)

Check out the OWASP Top Ten. Trying to maintain a black-list of all known bad input and all its variants is akin to an arms race in which you will always find yourself at the losing, reactionary end.

        http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

        -dZ.

Hope you're not trying to "enumerate the bad" (i.e looking at $foo ~= /<script/i in the input ... or even '<'). There are lots of ways to escape such validators. A great resource on some is here: http://ha.ckers.org/xss.html I say, unescape everything back to the browser (even email addresses). OWASP has a good resource: http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

Clearly, neither the author of the book, nor reviewer understand web security.

If you want to learn about securing web servers, why not read Ivan Ristic's Apache Security?

Apparently, from the topics discussed in this review, this book has nothing to do with writing secure applications using the Joomla Framework. Seriously, file permission? Using Nmap? Nessus? Talk about using the wrong tools for the job. Not even the Joomla Security page has anything do with actual web application security.

How about going over topics like secure session management, input validation, parameterized queries, output entity encoding, etc?

Take a clue from OWASP and skip this book.

I personally suggest Hacking Exposed: Web Applications This is an excellent book that got me into testing web security. OWASP is terrific for tools and best practices (I suggest WebScarab. If you read the aforementioned book, you will be well on your way to understanding web security! As for someone to test your site I wouldn't trust anyone to do it that wouldn't cost you an arm and a leg; however, there are some good network scanners out there (Nikito for one). You can also find many useful tools at sectools.org. NOTE: don't merely trust the output of these tools! They are useful for finding the obvious stuff, but seasoned hackers/security experts will routinely find holes that these miss! Good luck!

I personally suggest Hacking Exposed: Web Applications This is an excellent book that got me into testing web security. OWASP is terrific for tools and best practices (I suggest WebScarab. If you read the aforementioned book, you will be well on your way to understanding web security! As for someone to test your site I wouldn't trust anyone to do it that wouldn't cost you an arm and a leg; however, there are some good network scanners out there (Nikito for one). You can also find many useful tools at sectools.org. NOTE: don't merely trust the output of these tools! They are useful for finding the obvious stuff, but seasoned hackers/security experts will routinely find holes that these miss! Good luck!

+1 to the above. Like anything else, you pay for someone else's expertise, or you learn yourself.

The best and most through guide to web testing and security out there is to the Web Application Hackers Handbook, but the OWASP Testing Guide is a good intro and a free download you can start working with today.

PDF version
Main page

The best way to learn is by doing, and OWASP WebGoat is a good interactive learning environment. It's also quite easy to try out using the OWASP Live cd, which has many of the testing tools like burp, paros, etc and also webgoat ready to run.

There's also a fairly decent "white box" source code scanner for PHP called pixy. You may wish to check that out also.

If you want to pay someone, that's what I do for a living, and I know a decent number of others in the field if you want recommendations.

+1 to the above. Like anything else, you pay for someone else's expertise, or you learn yourself.

The best and most through guide to web testing and security out there is to the Web Application Hackers Handbook, but the OWASP Testing Guide is a good intro and a free download you can start working with today.

PDF version
Main page

The best way to learn is by doing, and OWASP WebGoat is a good interactive learning environment. It's also quite easy to try out using the OWASP Live cd, which has many of the testing tools like burp, paros, etc and also webgoat ready to run.

There's also a fairly decent "white box" source code scanner for PHP called pixy. You may wish to check that out also.

If you want to pay someone, that's what I do for a living, and I know a decent number of others in the field if you want recommendations.

+1 to the above. Like anything else, you pay for someone else's expertise, or you learn yourself.

The best and most through guide to web testing and security out there is to the Web Application Hackers Handbook, but the OWASP Testing Guide is a good intro and a free download you can start working with today.

PDF version
Main page

The best way to learn is by doing, and OWASP WebGoat is a good interactive learning environment. It's also quite easy to try out using the OWASP Live cd, which has many of the testing tools like burp, paros, etc and also webgoat ready to run.

There's also a fairly decent "white box" source code scanner for PHP called pixy. You may wish to check that out also.

If you want to pay someone, that's what I do for a living, and I know a decent number of others in the field if you want recommendations.

There are a number of web app security sites that will teach you how to test your website for security vulnerabilities. Even providing sample inputs for trying XSS and SQL-Injection attacks on your own site. Try these for starters:

http://www.owasp.org/
http://ha.ckers.org/xss.html

There are some good automated security scanners out there. For instance: Nesses/Nikto, WebScarab with proxmon, portswigger, and you can even go as far as using 3rd party companies such as HackerSafe.com or SecurityMetrics.com. Even though this doesn't give you a 100% fail-safe security scenario (*cough* nothing does and probably never will), it at least helps decrease the chances of common and even some more uncommon attacks such as SQL injections, overflows, man-in-the-middle attacks, etc. You also obviously have to write secure code and keep all of your software up to date (especially open source software). This is not only true for PHP, but for all programming languages. You should also try using BSD since you have a LAMP system. Some other good sources of information: http://www.webappsec.org/ http://www.owasp.org/ Hope this helps...

This video is a couple years old, but an interesting overview (Mike Andrews presenting at Google) http://www.youtube.com/watch?v=ZgW2B2gKZVw I'm sure OWASP has some decent info for you as well: http://www.owasp.org/index.php/Main_Page Good luck :)

The Open Web Application Security Project (OWASP) has a Top 10 list, which lists the most serious web application vulnerabilities, discusses how to protect against them, and provides links to more information (http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project). This might be a good start.

http://www.owasp.org/index.php/Main_Page

Your first stop should be OWASP, the Open Web Application Security Project. You'll find there many companies that are experts in web application security, including tools and guides to get a handle on web app sec. I'd also recommend becoming familiar with the OWASP Top 10 http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

Your first stop should be OWASP, the Open Web Application Security Project. You'll find there many companies that are experts in web application security, including tools and guides to get a handle on web app sec. I'd also recommend becoming familiar with the OWASP Top 10 http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

As someone who has worked in web security, let me say that many of us have been begging for stricter control over security protocols for years. With all the AJAX going around, more and more sites are proving vulnerable to browsers that are just too friendly with the same-origin policy. If you check out the OWASP Top 10, you'll see that a whole bunch of these attacks could be prevented by better browser security.

The best case would be a restructuring Javascript and the DOM as well, but I would be excited to see any increased security. After I used a reflected XSS attack to essentially gain control over a client's browser and all their cookies last year, I don't trust any web application.

I'm afraid you have no guarantee the code is unmodified - that's why I suggested it should be signed. You're also wrong about the cookies as they are accessible from javascript using document.cookie which means that any malicious script could access them (and even send them to a 3rd party). There is an HTTPOnly flag on cookies (an extension added in IE6sp1 but that flag has to be specifically set (see http://www.owasp.org/index.php/HTTPOnly for more details).

This is 5th on the OWASP top 10 list of vulnerabilities of the web applications. If you're writing one and don't know about the CSRF, then it probably good idea to read up a bit.

Not saying you are wrong, but why are there so many XSS issues if it is easy?

A combination of ignorance, apathy, and poor quality learning materials.

is there a "here is how to let your users make their comment pretty and link to other websites and not get hosed" FAQ?

Well the real answer to this is to point them to the sanitising features available for their particular platform/language/framework/etc. Generic advice is low-level by its very nature, for example XSS (Cross Site Scripting) Cheat Sheet or perhaps OWASP.

I'm a pretty smart guy, I think... at least open minded or something. I mean, at least I seem to know enough to worry about XSS issues but yet I dont find it easy at all. What am I missing here?

You're trying to do it yourself. Don't. Hand it off to a library.

Slashdot doesn't even do HTML filtering "elegantly". How can I type in those two fake tags as a comment AND quote you without escaping the brackets myself? I dont think this is as easy of a problem to solve as you think it is :-)

Slashdot is a mess all around, a lot of their problems are because their design strategy seems to be "accumulate features over time, never refactor, offer options instead of taking away obsolete features or being non-backwards-compatible". I mean, they have three different commenting systems, three different display systems and three different comment formats. That's hardly something to emulate. Having said that, they are probably one of the highest targets around for crapflooders, and they won that battle conclusively, which is clear evidence that it's not impossible to sanitise input. Slashcode is open-source, if there were a gap in its sanitation procedure, then Slashdot would quickly be overrun by trolls screwing up every page.

If you want to handle situations like this, then normalise the code, and escape every tag not on the whitelist. But the feature itself isn't really ideal because the user expectation of their comments being markup-but-not-in-some-cases is confusing.

Could it be that web developers have to create Web 2.0 applications that take all sorts of evil input? How do you make blogs, tags, message boards, and things 100% safe? I wish security researchers would create a proof of concept site that was a REAL web application to show best practices. Sure there are projects like http://www.owasp.org/, but their example code is near useless for most languages they have up.

Think about the input needed for a comment box. You have to deal with i18n issues. UTF-8 or UTF-16 is a very big character set. You can't explicitly block everything and then white list selectively very easily with such a big character set.

Some people think bbcode is the solution for some types of sites. I haven't seen too many implementations of bbcode for languages other than PHP that are open source and reusable.

Can someone point me at resources for Java and .NET development? I don't use PHP very often. Are there any resources for other languages like perl, python and ruby?

I'd personally love to get a library to do safe HTML input while stripping any dangerous tags in Java that is reasonably reusable.

There are specific methodologies for modeling risks / threats and estimating their impact, that are used for justifying
Information Security budgeting.

Principles of Information Security is one book that I'm familiar with that has quite a bit of coverage of this topic. We used this for my course in Information Security a couple of years ago, and I found it pretty useful, FWIW.

Additionally, check this OWASP Page for some good stuff.

And finally, try googling for terms like Security Risk Analysis, Security Risk Assessment, and / or Security Threat Modeling.

If you want to know about web application security visit owasp.org

...they were lazy and wanted it done fast

>> regexp should NEVER be used to protect against sql injection

false. regular expressions are great for positively matching valid input, but not for trying to catch all invalid input. if we're talking about a zipcode field, if I write a regular expression that will match against any alphabetic chars, sql chars, and anything else I think might be 'bad' input, then I'm an idiot and should look for a new job in a new field. If I instead write a regular expression that will positively match against valid zipcodes, and then i reject everything else, then i am safe (for this field at least) against sql injection. see http://www.owasp.org/ for some good specific examples of well formed regular expressions.

i don't mean to imply that regular expressions should be used in place of other techniques, but they can certainly be helpful when used correctly. parameterized sql is a great way to go.

I'm not aware of any way of exploiting a stack overflow for arbitrary code execution, though this isn't really my area of interest, so I could be wrong. Is there one?

A good quick and easy resource for coders who aren't seurity expects (myself included) is the Open Web Application Security Project, or OWASP for short. It's an open project aimed at documenting security risks in web applications and providing guidelines and examples on how to protect against them. Check it out: http://www.owasp.org/index.php/Category:OWASP_Guid e_Project

Although most of the examples are java, there's a really good PHP section in the guide. I always recommend web coders check that out and just take it all in, so coding secure websites becomes the "normal" way they code, so they do it without having to think about it.

It's really easy to write a stored proc that builds dynamic sql and calls "EXEC" or "EXECUTE" etc on that statement.

This powerpoint presentation is about the best I have read:

http://www.owasp.org/images/7/74/Advanced_SQL_Inje ction.ppt#369,93,Advanced%20SQL%20Injection

Remember folks, you have to do more than parameterize your queries.
m.

Security is a must for Web developers. There is a set of typical mistakes that are frequently made in Web applications, and most of them are not fixed automagically by using Java. Fortunately plenty of resources are available on the Net:

• The Open Web Application Security Project (OWASP) maintains a list of the Top Ten Most Critical Web Application Security Vulnerabilities and a Guide to Building Secure Web Applications. They also provide WebGoat, an application with typical vulnerabilities, for training purposes, and WebScarab, an interactive proxy for security analysis and general debugging. Both are Java applications, WebScarab running standalone and WebGoat in a Servlet container like Tomcat.
• The Web Application Security Consortium (WASC) publishes the Web Security Threat Classification, which is similar to the OWASP Top Ten, and other articles.

Make sure your developers read and understand this.

Security is a must for Web developers. There is a set of typical mistakes that are frequently made in Web applications, and most of them are not fixed automagically by using Java. Fortunately plenty of resources are available on the Net:

• The Open Web Application Security Project (OWASP) maintains a list of the Top Ten Most Critical Web Application Security Vulnerabilities and a Guide to Building Secure Web Applications. They also provide WebGoat, an application with typical vulnerabilities, for training purposes, and WebScarab, an interactive proxy for security analysis and general debugging. Both are Java applications, WebScarab running standalone and WebGoat in a Servlet container like Tomcat.
• The Web Application Security Consortium (WASC) publishes the Web Security Threat Classification, which is similar to the OWASP Top Ten, and other articles.

Make sure your developers read and understand this.

Security is a must for Web developers. There is a set of typical mistakes that are frequently made in Web applications, and most of them are not fixed automagically by using Java. Fortunately plenty of resources are available on the Net:

• The Open Web Application Security Project (OWASP) maintains a list of the Top Ten Most Critical Web Application Security Vulnerabilities and a Guide to Building Secure Web Applications. They also provide WebGoat, an application with typical vulnerabilities, for training purposes, and WebScarab, an interactive proxy for security analysis and general debugging. Both are Java applications, WebScarab running standalone and WebGoat in a Servlet container like Tomcat.
• The Web Application Security Consortium (WASC) publishes the Web Security Threat Classification, which is similar to the OWASP Top Ten, and other articles.

Make sure your developers read and understand this.

Security is a must for Web developers. There is a set of typical mistakes that are frequently made in Web applications, and most of them are not fixed automagically by using Java. Fortunately plenty of resources are available on the Net:

• The Open Web Application Security Project (OWASP) maintains a list of the Top Ten Most Critical Web Application Security Vulnerabilities and a Guide to Building Secure Web Applications. They also provide WebGoat, an application with typical vulnerabilities, for training purposes, and WebScarab, an interactive proxy for security analysis and general debugging. Both are Java applications, WebScarab running standalone and WebGoat in a Servlet container like Tomcat.
• The Web Application Security Consortium (WASC) publishes the Web Security Threat Classification, which is similar to the OWASP Top Ten, and other articles.

Make sure your developers read and understand this.

Security is a must for Web developers. There is a set of typical mistakes that are frequently made in Web applications, and most of them are not fixed automagically by using Java. Fortunately plenty of resources are available on the Net:

• The Open Web Application Security Project (OWASP) maintains a list of the Top Ten Most Critical Web Application Security Vulnerabilities and a Guide to Building Secure Web Applications. They also provide WebGoat, an application with typical vulnerabilities, for training purposes, and WebScarab, an interactive proxy for security analysis and general debugging. Both are Java applications, WebScarab running standalone and WebGoat in a Servlet container like Tomcat.
• The Web Application Security Consortium (WASC) publishes the Web Security Threat Classification, which is similar to the OWASP Top Ten, and other articles.

Make sure your developers read and understand this.

I've just started considering these questions in preparation to handle some online creditcard processing.

I had thought about the "require a password on server startup to decrypt the passwords into RAM" method, but that prevents unattended server restarts and so in the (hopefully rare) case of an unscheduled service/process restart you'd have to get onto the server and enter the password before the application would be available again. Not optimal in my opinion.

Regarding best practices I've found The Open Web Application Security Project and the Credit Card industry's PCI Data Security Standard. Visa's implemention is called CISP.

Both seem to recommend a multi-level security strategy with numerous barriers between the outside world and your data.

Another thought: If you only need administrative access to the data or don't need to access it from that machine at all, using a public key encryption scheme would probably work well.

.jonah

For background information I highly recommend the Open Web Application Security Project http://www.owasp.org/ There are local chapters all over the world that should have regular meetings - I help run the San Antonio chapter.

The important thing is to target any training so that it matches the background of those being trained. I have done work with with IT Audit groups and they wanted to learn how to do application security assessments themselves. Given their background this simply was not in the cards so we instead focused their attention on how to audit the assessment process to make sure that tools were being used properly and the outcomes of the assessments was being addressed by the development teams. Training for network security folks can include how to run scanning tools and interpret the results, as well as how to do some manual testing of their own. Developers can obviously learn about the assessment process, but will ultimately need training on how to design and code secure systems. In any case, the important thing is to match the training being given with the job responsibilities and capabilities of those being trained.

As for groups that do this sort of training, obviously I am biased, but my company Denim Group http://www.denimgroup.com/ does application security security training for developers, auditors, QA and network security folks. McAfee and Symantec offer courses as well.

Thanks,

Dan

One live site

• http://www.testfire.net/

And a number of "targets" where you supply your own hardware,

• WebGoat download from http://www.owasp.org/software/webgoat.html
• Foundstone's Hacme Bank application download from http://www.foundstone.com/resources/s3i_tools.htm

I'm absolutely *not* a Java fan, but feel compelled to mention that an app that's vital for my work (infosec stuff) - the WebScarab web proxy, which allows easy drilling into HTTP requests, on the fly manipulation of cookies, form arguments and so on, and which is perfectly quick enough for me.

The issues that were stated about PHP, really apply to ANY language. SQL injection flaws can existing in PHP, Perl, Java, and .NET.

The reason you don't find much about "secure PHP", is that it's not just a PHP issue. You might want to read sites like OWASP (http://www.owasp.org/) and Threats&Countermeasures (http://www.threatsandcountermeasures/). There are plenty of others.

The thing is, it's not as simple to write a "how to" when it comes to security issues. It's a bit more abstract than that, if you try to encompass the whole concept. For example... SQL injection flaws:

Never take anything string of data that came from the user and stick it into the SQL string you are generating, without checking it for a few basic things. Escape ANY special characters that has meaning in SQL (quotes, semi-colons, etc). Quotes are your biggest threat. Quick example:

You are building this string:
"SELECT count(*) from users where username = '$username'";

Now imaging $username came directly from user input, and I typed:
'; delete from users; --

That results in a query like:
SELECT count(*) from users where username = ''; delete from users; --'

Assuming your driver or database doesn't limit single "prepare" or query executes to only one statement, it will run the select, and then delete all users, commenting anything else you would have had after that. Scary, huh?

The best thing is to look for API's that support prepare and execute of a query separately, where you place "?" placeholder in the SQL query string, and then give the data to the execute method. The execute method generally handles all escaping needs to treat it as "data". Clear separation of command and data. Of course, that's not 100%, as you could have a "LIKE" comparisson in your WHERE clause. A "%" in the data is still treated as a wildcard, so you would still have to be sure to escape that in variables you are using with where clause values.

So, there's your simple brief tutorial... but the whole way of thinking is different if you consider all the vulnerabilities. Read OWASP's top 10 list, and think about you are providing information and using information to/from the user. These are your attack surfaces.

Cheers,
Your friendly neighborhood Application Security Specialist