This little fable describes the most common vulnerability found in web sites, the Cross Site Scripting (XSS) attack. According to a report from WhiteHat Security 83 percent of websites they tested have had at least one serious vulnerability and 66 percent of all websites with vulnerabilities are susceptible to XSS attacks making it the most common vulnerability web developers face. To fix this, it takes 67 days on average. Tools like WebScarab and Paros Proxy can be used to scan sites for possible vulnerabilities.

They offer two simple pieces of advice that it's all too easy to forget when developing applications - validate all user input to ensure it's what it should be and escape any untrusted output (even sometimes your own!) before pushing it out to the page.

Cross-Site Scripting (XSS) is a type of attack where a hacker attempts to inject client-side scripting into a webpage that others are able to view. The attack could be as simple as an annoying alert window or as sophisticated as stealing a logged in user's credentials (commonly saved in browser cookies). [...] Since these types of user input can immediately be displayed to other user's, the attack could be spread pretty quickly and even without your knowledge.

He provides a basic function to get you started filtering the input from your users - a "xss_protect" method that takes in the data, whether to strip HTML tags or not and an optional set of allowed tags if you do. He also asks for opinions and better methods in his comments:

No solution is going to be perfect, but at least now you have a head start! If you have ways of improving this function, let myself and everyone else know in the comments.

EllisLabs' news release for CodeIgniter 2.0.2 makes mention of "a small vulnerability". This small vulnerability is mentioned no where else (not even the actual changelog for 2.0.2). In reality, I reported seven distinct vulnerabilities across two classes. These vulnerabilities might allow an attacker to inject arbitrary HTML, CSS or Javascript, i.e. Cross-Site Scripting (XSS) into an application's output.

He gives a list of four recommendations that CodeIgniter 2.0.2 users can take to creating (or updating) their applications including using HTMLPurifier when you need sanitization and ensuring that views and templates from third parties are clear of XSS issues.

Security is a very important aspect of programming. In PHP, there are few useful functions which is very handy for preventing your website from various attacks like SQL Injection Attack , XSS attack etc.Let's check few useful functions available in PHP to tighten the security in your project. But note that this is not a complete list, it just list of functions which I found useful for using in your project.

The functions include mysql_real_escape_string for database query handling, htmlentities to filter user input for HTML and two hashing functions to create hashes you can validate from - md5 and sha1.

While an ongoing process, the initial [security] review focused on specific areas most likely to deal directly or indirectly with user input and the output of user sourced data. [...] The review also included an examination of all new components due to enter service with Zend Framework 1.10. This yielded a number of issues whose fixes will preempt their release into a stable version, and have been reported to the relevant lead developers.

Padraic mentions some of the things that were found and corrected in these security releases including the enforcement of a default character set throughout the framework (with new functions to help with keeping your data consistent) and several potential XSS vulnerabilities in components like the Zend_Json, Zend_Dojo_View_Helper_Editor and Zend_Filter_StripTags.

I thought about something I found ages ago in PHP4 and it's been long enough now. This is also quite funny because my server is vulnerable to this. So what happens if you escape PHP_SELF with htmlentities($_SERVER['PHP_SELF'], ENT_QUOTES)? Safe from XSS? I hope so. Safe from everything? Well not really or at least it didn't used to be.

He gives a simple example of how the PHP_SELF issue can be used to change the form's target just by using a few well-placed slashes. Thankfully, this seems to be only back in the world of PHP4, so those working with PHP5 should be safe.

Recently I taught a class of bright-eyed, bushy-tailed PHP'ers just getting their start in the world. They haven't done their first production application and we were working in the "safe" confines of a classroom, but there was one concept that I pounded into their heads: Don't Trust the Users.

Generally, as Keith mentions, users aren't malicious/incompetent/ignorant 99 percent of the time, but there's always that off chance that they are and you need to protect you and your application from it by filtering input and escaping all output to prevent any mishaps.

It's really hard to decide what data is acceptable, especially when user has permission to insert HTML content through form. [...] However, problem can be solved, and quite easily. Almost a year ago I was reading some random blog when I find out about HTML Purifier. Basically, it's library which can filter and fix any HTML.

He gives an example - running a web scraping tool against a site with malformed HTML. By running it through the HTML_Purifier package first, the errors were corrected and the "more correct" HTML source could be parsed easily. The package also helps to protect from XSS attacks via a whole set of filters included by default.

The phenomenal growth of PHP applications has also led to a mushrooming of increased quantum of malicious activity. It thus becomes imperative that you write secure PHP code to protect your website. Here are some tips for the same. The three most vulnerable aspects of PHP that can become easily accessible to anyone are XSS (Cross Site Scripting), Global Variables and SQL code.

He details what each is and how you can protect your code against the problems they cause. Some example code is included to give you a better idea of the possible solution.

CSRF, or Cross-Site Request Forgery, is a vulnerability very common in websites. [...] This can be dangerous, especially if your admin interface is compromised: There may be a button on the other site which goes to your admin interface and deletes the latest blogpost for example - and you wouldn't want that!

His method is a three-step process for protection - use POST, protect against cross-site scripting and use a CSRF key in the form to help prevent abuse. A simple script is included to show it working and is adapted to work in a controller plugin for the Zend Framework.