[Owasp-leaders] OWASP Top 10 2012

Somen Das somen.das at owasp.org
Tue Oct 11 10:49:25 EDT 2011


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
browser.
> < ( ) [ ] ' " ; : / |

*Java*
Vulnerable code:
Consider the following code:
<% String sid = request.getParameter("sid"); %>
...
Student ID: <%= sid %>

Filtering:
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*/

*PHP*
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:
" style="background:url(JavaScript:alert(Malicious Content));
*ASP.NET
*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.
>
>  thanks,
> Andrew
>
> * 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,
> ~Venki
>
> 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):
>>
>>    1. Security Architecture (including incorporating agile ideas)
>>    2. Use a (more) secure development frameworks and leverage enterprise
>>    frameworks (UAG, etc)
>>    3. Input validation
>>    4. Output Encoding
>>    5. Identity: Authentication and Session Management
>>    6. Access Control (service / controller, data, URL, function / CSRF,
>>    presentation, etc)
>>    7. Data Protection (Data at rest, including in cloud)
>>    8. Audit, Logging and Error Handling
>>    9. Secure Configuration
>>    10. 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.
>>
>> Thoughts?
>>
>> thanks,
>> Andrew
>>
>> _______________________________________________
>> OWASP-Leaders mailing list
>> OWASP-Leaders at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>
>>
>
>
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-leaders/attachments/20111011/970820e1/attachment-0001.html 


More information about the OWASP-Leaders mailing list