[Owasp-leaders] OWASP Top 10 2012
mark at curphey.com
Tue Oct 11 10:54:47 EDT 2011
FYI your advice for ASP.net is not what we (msft) recommend for XSS protection. Use anti-xss lib. It's what we built it for. Your recommendation has several issues.
Sent from my iPhone
On Oct 11, 2011, at 7:49 AM, Somen Das <somen.das at owasp.org> wrote:
> Dear All,
> I some what agree with venkatesh, where in if examples can be given for individual languages againt XSS or SQLi developers from respective fields can understand what is wrong & what they need to do. For example:
> Cross-site scripting vulnerability The following characters can be harmful and should be filtered whenever they appear in the application input or output. In output, you should translate these characters to their HTML equivalents before returning data to the
> > < ( ) [ ] ' " ; : / |
> Vulnerable code:
> Consider the following code:
> <% String sid = request.getParameter("sid"); %>
> Student ID: <%= sid %>
> The safest and most prevalent method of preventing against attack is to only accept data that is valid and reject everything else. For example, if the data is expected to be alphanumeric, then any input that is not should be rejected.
> String Str = request.getParameter("input");
> String Pattern = "^\\d+$";
> if (!Str.matches(Pattern))
> /* invalid input, take appropriate action*/
> The following PHP functions help mitigate Cross-Site Scripting Vulnerabilities:
> Strip_tags() removes HTML and PHP scripting tags from a string.
> Utf8_decode() converts UTF-8 encoding to single byte ASCII characters. Decoding Unicode input prior to filtering it
> can help you detect attacks that the attacker has obfuscated with Unicode encoding.
> Htmlspecialcharacters() turns characters such as &,>,<,” into their HTML equivalents. Converting special
> characters to HTML prevents them from being executable within browsers when sent by an application.
> Strtr() filters any characters you specify. Make sure to filter “; : ( )” characters so that attackers cannot craft strings
> that generate alerts. Many XSS attacks are possible without the use of HTML characters, so filtering and encoding
> parentheses mitigates these attacks. For example:
> With ASP.NET, you can use the following functions to help prevent Cross-Site Scripting:
> · Constrain input submitted via server controls by using ASP.NET validator controls, such as RegularExpressionValidator, RangeValidator, and System.Text.RegularExpression.Regex. Using these methods as server-side controls to limit data input to only allowable character sequences by validating input type, length, format, and character range.
> · Use the HtmlUtility.HtmlEncode method to encode data if it originates from either a user or from a database.
> HtmlEncode replaces special characters with their HTML equivalents, thus preventing the output from being executable in the browser. Use HtmlUtility.UrlEncode when writing URLs that may have originated from user input or stored database information.
> · Use the HttpOnly cookie option for added protection.
> · As a best practice, you should use regular expressions to constrain input to known safe characters. Do not rely solely on ASP.NET validateRequest, but use it in addition to your other input validation and encoding mechanisms.
> Thanks & stay secure,
> Somen das
> Chapter Leader Bhubaneswar
> On Tue, Oct 11, 2011 at 7:48 PM, Andrew van der Stock <vanderaj at owasp.org> wrote:
> These are all great ideas, but it's bed time for me as I have to get up in 5 hours time.
> In some ways, this proactive project is a perfect Level 1 ASVS starter criteria, leaving Levels 2-4 to cope with ever more increasing requirements.
> Although completely imperfect to me (and has been for years), there are many who probably would be very surprised / upset if every original OWASP Top 10 control changed between 2010 and 2012 editions. So probably best to make a new project that doesn't distort the existing 2012 process or resulting document. Hopefully, the new proactive project can get some serious marketing oomph / promotion so as to get some traction outside of traditional OWASP Top 10 consumers.
> @Anyone on the projects committee - can you please help create a
> "OWASP Top 10 Proactive Controls"
> project and mail list? I will fill in any necessary electronic wiki bits and pieces, forms etc - but after I wake up.
> Although I like the idea of calling it "OWASP Appsec TODO:", the reality is that I want it to encompass the business folks, too, and they may not get the TODO: reference*.
> I've been looking for a graceful way to bow out of the Global Chapter Committee for a while whilst still remaining involved with OWASP, and I think I've just found it. The GCC meeting times are just too difficult for me to get to now that I don't work from home. This project sounds like a potentially very valuable project in its own right, particularly if we can coordinate with / revitalise the ASVS project.
> * My code often has XXX: comments, but that's not suitable for a project title ;-)
> On 12/10/2011, at 12:54 AM, Venkatesh Jagannathan wrote:
>> I am *ALL* for this. Can we get a project started on this? You can count me in for contributing to this project :)
>> Thanks & Regards,
>> On Tue, Oct 11, 2011 at 4:43 PM, Andrew van der Stock <vanderaj at owasp.org> wrote:
>> One of the things I'd really like for the Top 10 2012 is to stop focusing on the things that went wrong in the previous 12 months, and start to concentrate on the Top 10 things to get right for the next five years. The existing Top 10 regularly gets incorporated without permission into various other standards, and it's 100% the wrong way around for that purpose. The Top 10 was never designed to be a standard.
>> To address this, here's my short list (in order):
>> Security Architecture (including incorporating agile ideas)
>> Use a (more) secure development frameworks and leverage enterprise frameworks (UAG, etc)
>> Input validation
>> Output Encoding
>> Identity: Authentication and Session Management
>> Access Control (service / controller, data, URL, function / CSRF, presentation, etc)
>> Data Protection (Data at rest, including in cloud)
>> Audit, Logging and Error Handling
>> Secure Configuration
>> Secure Communications (Data in transit)
>> All of the items must be testable. All items must be positively framed and eliminate entire CWE classes in their own right.
>> OWASP-Leaders mailing list
>> OWASP-Leaders at lists.owasp.org
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OWASP-Leaders