Code Review Looking for a vulnerable code Vlad Savitsky http://donetsk.drupal.ua
Code Review Looking for a vulnerable code
Twitter: У нас ввели code-review. –  А это как? –  Ну как, сидишь, читаешь код, ревёшь... http://twitter.com/#!/dallaylaen...
Overview <ul><li>Why  review code? </li></ul><ul><li>Who  should do code review? </li></ul><ul><li>Code  Review or  Person...
Why review code? <ul><li>Increase code quality. </li></ul><ul><li>Developers can learn new code. </li></ul><ul><li>Learn n...
What you shouldn't review? <ul><li>Bugs and mistakes. </li></ul><ul><li>Coding Standard compliance. </li></ul>
When  code should be reviewed? <ul><li>Before  merging to trunk. </li></ul><ul><li>Easy to  review small pieces  of code. ...
When  code should be reviews? <ul><li>Before  adding new code to project. </li></ul><ul><ul><li>Contrib  modules/themes </...
Who should do code review? <ul><li>Team Lead </li></ul><ul><li>Other developers </li></ul>
Code Review  or Person Review <ul><li>Developers  associate themselves  with their code. </li></ul><ul><li>Team  Conflicts...
Golden Rule of Code Review <ul><li>Do others code review </li></ul><ul><li>as you want they </li></ul><ul><li>do your code...
 
Goal of Code Review Perfect code  made by not perfect  developers.
How to find a vulnerability?
 
Find XSS <ul><li>Find and inspect theme() functions. </li></ul><ul><li>Does t() function used with proper placeholders. </...
 
SQL injection <ul><li>Bad code: </li></ul><ul><li>db_query('SELECT foo FROM {table} t WHERE t.name = '. $_GET['user']); </...
Bad smelling code <ul><li>Bad smelling code in most cases should be refactored. </li></ul><ul><li>http://sourcemaking.com/...
Drupal Security Team
Goals of the security team <ul><li>Resolve  reported security issues. </li></ul><ul><li>Provide assistance  for contribute...
How to report a security issue <ul><li>Do not post  in the issue tracker or discuss it in IRC. </li></ul><ul><li>Mail  to ...
How the security team  works with issues <ul><li>Review the issue and  evaluate the potential impact  on all supported rel...
Issues with contributed modules <ul><li>The module maintainer is  contacted with a deadline . </li></ul><ul><li>When the m...
Happy Code Review!!!
Questions? <ul><li>Question #1 </li></ul><ul><li>Question #2 </li></ul><ul><li>Question #3 </li></ul>
Upcoming SlideShare
Loading in …5
×

Code Review Looking for a vulnerable code. Vlad Savitsky.

1,098 views

Published on

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,098
On SlideShare
0
From Embeds
0
Number of Embeds
94
Actions
Shares
0
Downloads
23
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Highly Critical - Remotely exploitable vulnerabilities that can compromise the system. Interaction is not normally required for this exploit to be successful. Exploits have occurred to systems. Previous examples include: Local file inclusion on Windows, Impersonation, privilege escalation Critical - Remotely exploitable Denial of Service (DOS) vulnerabilities that can compromise the system but do require user interaction. Vulnerabilities that may allow anonymous users (i.e. users not registered at the site) to log in as a site user or take administrative actions. Interaction (such as an administrator viewing a particular page) may be required for this exploit to be successful, or in cases where interaction is not required (such as CSRF) the exploit causes only minor damage. Previous examples include: OpenID impersonation, SQL injection Moderately Critical (3 of 5): Remotely exploitable vulnerabilities that can compromise the system. Interaction (such as an administrator viewing a particular page) is required for this exploit to be successful. Exploits have not yet occurred on systems when vulnerability was disclosed. The exploit requires the user to be registered at the site and have some non-default permission, such as creating content. Previous examples include: Cross Site Scripting, Access bypass Less Critical (2 of 5): Used for cross-site request forgery vulnerabilities as well as privilege escalation vulnerabilities which require complex chains of events. This rating also includes vulnerabilities which might expose sensitive data to local users. Previous examples include: Session fixation, Cross site request forgery Not Critical (1 of 5): Rating is used for limited privilege escalation vulnerabilities and locally Denial of Service (DOS) vulnerabilities. Previous examples include: Access bypass
  • Code Review Looking for a vulnerable code. Vlad Savitsky.

    1. 1. Code Review Looking for a vulnerable code Vlad Savitsky http://donetsk.drupal.ua
    2. 2. Code Review Looking for a vulnerable code
    3. 3. Twitter: У нас ввели code-review. – А это как? – Ну как, сидишь, читаешь код, ревёшь... http://twitter.com/#!/dallaylaen/status/129887114576920577
    4. 4. Overview <ul><li>Why review code? </li></ul><ul><li>Who should do code review? </li></ul><ul><li>Code Review or Person Review </li></ul><ul><li>How to find a vulnerability? </li></ul><ul><li>How to report about security problem? </li></ul>
    5. 5. Why review code? <ul><li>Increase code quality. </li></ul><ul><li>Developers can learn new code. </li></ul><ul><li>Learn new code best practices. </li></ul><ul><li>To check if code is clear and easy to understand. </li></ul><ul><li>Find vulnerable code. </li></ul>
    6. 6. What you shouldn't review? <ul><li>Bugs and mistakes. </li></ul><ul><li>Coding Standard compliance. </li></ul>
    7. 7. When code should be reviewed? <ul><li>Before merging to trunk. </li></ul><ul><li>Easy to review small pieces of code. </li></ul><ul><li>Often is better. </li></ul>
    8. 8. When code should be reviews? <ul><li>Before adding new code to project. </li></ul><ul><ul><li>Contrib modules/themes </li></ul></ul><ul><ul><li>Custom modules/themes </li></ul></ul><ul><li>Easy to review small pieces of code. </li></ul><ul><li>Often is better. </li></ul>
    9. 9. Who should do code review? <ul><li>Team Lead </li></ul><ul><li>Other developers </li></ul>
    10. 10. Code Review or Person Review <ul><li>Developers associate themselves with their code. </li></ul><ul><li>Team Conflicts </li></ul><ul><li>Ability to learn best practices . </li></ul>
    11. 11. Golden Rule of Code Review <ul><li>Do others code review </li></ul><ul><li>as you want they </li></ul><ul><li>do your code review. </li></ul>
    12. 13. Goal of Code Review Perfect code made by not perfect developers.
    13. 14. How to find a vulnerability?
    14. 16. Find XSS <ul><li>Find and inspect theme() functions. </li></ul><ul><li>Does t() function used with proper placeholders. </li></ul><ul><li>Does check_plain() or theme('placeholder') used for plain text? </li></ul><ul><li>Does check_markup() or filter_xss() used for markup containing text? </li></ul>
    15. 18. SQL injection <ul><li>Bad code: </li></ul><ul><li>db_query('SELECT foo FROM {table} t WHERE t.name = '. $_GET['user']); </li></ul><ul><li>Good code: </li></ul><ul><li>db_query(&quot;SELECT foo FROM {table} t WHERE t.name = '%s' &quot;, $_GET['user']); </li></ul><ul><li>Does Database API used correctly? </li></ul>
    16. 19. Bad smelling code <ul><li>Bad smelling code in most cases should be refactored. </li></ul><ul><li>http://sourcemaking.com/refactoring/bad-smells-in-code </li></ul>
    17. 20. Drupal Security Team
    18. 21. Goals of the security team <ul><li>Resolve reported security issues. </li></ul><ul><li>Provide assistance for contributed module maintainers in resolving security issues. </li></ul><ul><li>Provide documentation on how to write secure code . </li></ul><ul><li>Provide documentation on securing your site </li></ul>
    19. 22. How to report a security issue <ul><li>Do not post in the issue tracker or discuss it in IRC. </li></ul><ul><li>Mail to security@drupal.org </li></ul><ul><li>Provide as many details as you can. At least: </li></ul><ul><ul><li>Drupal version and/or module version. </li></ul></ul><ul><ul><li>Steps to reproduce the problem. </li></ul></ul><ul><li>Do not disclose the vulnerability to anyone before the advisory is issued. </li></ul><ul><li>You will be credited in the security announcement </li></ul>
    20. 23. How the security team works with issues <ul><li>Review the issue and evaluate the potential impact on all supported releases of Drupal. </li></ul><ul><li>If it is indeed a valid problem, the security team is mobilized to eliminate it . </li></ul><ul><li>New versions are created and tested. </li></ul><ul><li>New packages are created and uploaded to Drupal.org. </li></ul><ul><li>When an issue has been fixed, use all available communication channels to inform users of steps that must be taken to protect themselves. </li></ul>
    21. 24. Issues with contributed modules <ul><li>The module maintainer is contacted with a deadline . </li></ul><ul><li>When the maintainer fixes the problem, the security team issues an advisory. </li></ul><ul><li>If the maintainer does not fix the problem within the deadline, an advisory is issued, recommending disabling the module and the project on Drupal.org is unpublished. </li></ul>
    22. 25. Happy Code Review!!!
    23. 26. Questions? <ul><li>Question #1 </li></ul><ul><li>Question #2 </li></ul><ul><li>Question #3 </li></ul>

    ×