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