Drupal core is a secure product, but how secure are contrib modules? And custom ones?
This session is about proper use of the drupal api's and some best practices for secure drupal development.
OWASP Top 10 at International PHP Conference 2014 in BerlinTobias Zander
With the latest XSS and CSRF attacks on Twitter, PayPal and Facebook, security is still obviously a very difficult thing to get right.
Every 3 years, the open web application security project (OWASP) releases a new Top 10 vulnerabilities, this talk will walk you through 2013s list.
I'll present you the possible attack scenarios and how you can protect against them.
In addition we'll look at more security issues which are not part of the Top 10, but that you should definitely keep in mind.
Mike Creuzer's presentation from the December, 2009 Suburban Chicago PHP & Web Dev Meetup. The topic is SQL injection in PHP and common PHP content management systems.
Visit Mike's blog at http://mike.creuzer.com/
Making Joomla Insecure - Explaining security by breaking itTim Plummer
This document summarizes a presentation about making Joomla insecure and how to protect against common vulnerabilities. It demonstrates how to introduce vulnerabilities like SQL injection, local file inclusion, and cross-site scripting. It then provides tips to secure a Joomla site, such as sanitizing user input, updating to the latest version, using strong passwords, checking for file existence, and more. The goal is to make attendees aware of potential risks and how to properly secure a Joomla website.
Greg Anderson presents on using Selenium to automate web application security testing. He demonstrates using Selenium to test for XSS and SQL injection vulnerabilities. He shows how to write Selenium tests to inject payloads and validate results, and discusses incorporating the tests into a continuous integration pipeline to help security teams keep up with development cycles.
This document provides an overview of SQL injection (SQLi), including what it is, how to detect and exploit it, and how to prevent it. SQLi allows attackers to interfere with and extract data from SQL queries by inserting malicious SQL code. It can be used to bypass authentication, obtain sensitive information, alter or delete database content, and execute remote commands. The document outlines manual and automated testing techniques for detecting SQLi vulnerabilities and tools like SQLMAP for exploiting them. It also discusses prevention best practices.
The document provides best practices for developing WordPress plugins, including using unique function names prefixed with the plugin name, escaping values to prevent vulnerabilities, not assuming file locations which can change, using plugins_url() to reference plugin files rather than hardcoding URLs, properly enqueueing styles and scripts, adding custom hooks for extensibility, and leveraging WordPress's flexibility through custom post types and custom tables. Developers are encouraged to structure plugins for maximum compatibility, security and flexibility.
OWASP Top 10 at International PHP Conference 2014 in BerlinTobias Zander
With the latest XSS and CSRF attacks on Twitter, PayPal and Facebook, security is still obviously a very difficult thing to get right.
Every 3 years, the open web application security project (OWASP) releases a new Top 10 vulnerabilities, this talk will walk you through 2013s list.
I'll present you the possible attack scenarios and how you can protect against them.
In addition we'll look at more security issues which are not part of the Top 10, but that you should definitely keep in mind.
Mike Creuzer's presentation from the December, 2009 Suburban Chicago PHP & Web Dev Meetup. The topic is SQL injection in PHP and common PHP content management systems.
Visit Mike's blog at http://mike.creuzer.com/
Making Joomla Insecure - Explaining security by breaking itTim Plummer
This document summarizes a presentation about making Joomla insecure and how to protect against common vulnerabilities. It demonstrates how to introduce vulnerabilities like SQL injection, local file inclusion, and cross-site scripting. It then provides tips to secure a Joomla site, such as sanitizing user input, updating to the latest version, using strong passwords, checking for file existence, and more. The goal is to make attendees aware of potential risks and how to properly secure a Joomla website.
Greg Anderson presents on using Selenium to automate web application security testing. He demonstrates using Selenium to test for XSS and SQL injection vulnerabilities. He shows how to write Selenium tests to inject payloads and validate results, and discusses incorporating the tests into a continuous integration pipeline to help security teams keep up with development cycles.
This document provides an overview of SQL injection (SQLi), including what it is, how to detect and exploit it, and how to prevent it. SQLi allows attackers to interfere with and extract data from SQL queries by inserting malicious SQL code. It can be used to bypass authentication, obtain sensitive information, alter or delete database content, and execute remote commands. The document outlines manual and automated testing techniques for detecting SQLi vulnerabilities and tools like SQLMAP for exploiting them. It also discusses prevention best practices.
The document provides best practices for developing WordPress plugins, including using unique function names prefixed with the plugin name, escaping values to prevent vulnerabilities, not assuming file locations which can change, using plugins_url() to reference plugin files rather than hardcoding URLs, properly enqueueing styles and scripts, adding custom hooks for extensibility, and leveraging WordPress's flexibility through custom post types and custom tables. Developers are encouraged to structure plugins for maximum compatibility, security and flexibility.
Drupal Security from Drupalcamp BratislavaGábor Hojtsy
Gábor Hojtsy presented on Drupal security at Drupalcamp Bratislava in 2010. He discussed common security risks like injection, cross-site scripting, authentication issues and how Drupal addresses them through secure APIs and modules. The Drupal security team works to ensure the security of Drupal core and contributed modules by finding and fixing vulnerabilities and educating developers on secure coding practices. While open source can increase scrutiny, it also multiplies eyes finding and addressing issues for more secure software.
OWASP Top 10 vs Drupal - OWASP Benelux 2012ZIONSECURITY
The document discusses securing Drupal against the OWASP Top 10 vulnerabilities. It provides examples of how vulnerabilities like SQL injection, XSS, session hijacking, insecure direct object references, CSRF, misconfiguration issues and failure to restrict URL access could occur in Drupal. It also explains the security measures Drupal has implemented, such as input filtering, form tokens, access control and encryption to address these risks.
Rails security best practices involve defending at multiple layers including the network, operating system, web server, web application, and database. The document outlines numerous vulnerabilities at the web application layer such as information leaks, session hijacking, SQL injection, mass assignment, unscoped finds, cross-site scripting (XSS), cross-site request forgery (CSRF), and denial-of-service attacks. It provides recommendations to address each vulnerability through secure coding practices and configuration in Rails.
All about web application security and common threats and how to counter measure these threats
The content of this presentation was derived from several notable Drupal SA team like Greg Knaddison, Khalid Baheyeldin, Heine Deelstra, and Dave Reid.
Special thanks to Greg's book "Cracking Drupal: A Drop in the Bucket".
This document discusses securing Drupal websites. It covers common Drupal attacks like XSS and SQL injection and recommends countermeasures like keeping software updated, following coding standards, sanitizing user input, and penetration testing. The document also provides an overview of securing the web server, PHP, and the Drupal codebase through permissions, input validation, and file uploads.
Gábor Hojtsy gave a presentation on doing Drupal security right. He discussed common web application security risks like SQL injection, cross-site scripting, and insecure direct object references. He explained how Drupal addresses these issues through features like input filtering, form tokens, and access control. Hojtsy emphasized that while Drupal provides secure APIs, developers must use them properly. He also discussed Drupal's open security team that works to find and fix vulnerabilities in Drupal core and contributed modules.
Gábor Hojtsy presented on Drupal security at Drupalcamp Bratislava. He discussed the top security risks for Drupal sites like insecure server configurations, weak passwords, and cross-site scripting vulnerabilities. Hojtsy explained the proper Drupal approaches to mitigate these risks, such as using strong passwords, keeping software updated, sanitizing user input, and leveraging Drupal's built-in security features like form tokens. He also covered the work of the Drupal security team to help ensure the core framework and contributed modules are secure.
Doing Drupal security right from Drupalcon LondonGábor Hojtsy
This document summarizes a presentation on doing Drupal security right. It discusses common security issues like SQL injection, cross-site scripting, authentication and session security. It provides the Drupal approach to addressing each issue through secure APIs and modules. It also discusses open source security in general and notes that Drupal security is supported by a volunteer team working to ensure the security of Drupal core and contributed projects.
Tips on Securing Drupal Sites - DrupalCamp Atlanta (DCA)cgmonroe
This is an updated version of this talk given at DrupalCamp Atlanta (DCA)
This presentation is an overview / case study of things learned by experiencing GDPR Security audits, DoS attacks, brute force login attacks, annoying robot crawlers, and hackers doing security probes.
The session will cover the following main topics with tips on how to protected against each of these.
An overview of security threats
Server Level Attacks
Code Level Attacks
User Access Attacks
Internal Attacks
Some suggestions on developing a security plan
People attending should come away with useful knowledge (modules, best practices, sites that help, front end tools and the like) that will help secure their sites.
The security of an application is a continuous struggle between solid proactive controls and quality in SDLC versus human weakness and resource restrictions. As the pentester's experience confirms, unfortunatelly even in high-risk (e.g. banking) applications, developed by recognized vendors, the latter often wins - and we end up with critical vulnerabilities.
One of the primary reasons is lack of mechanisms enforcing secure code by default, as opposed to manual adding security per each function. Whenever the secure configuration is not default, there will almost inevitably be bugs, especially in complex systems. I will pinpoint what should be taken into consideration in the architecture and design process of the application. I will show solutions that impose security in ways difficult to circumvent unintentionally by creative developers. I will also share with the audience the pentester's (=attacker's) perspective, and a few clever tricks that made the pentest (=attack) painful, or just rendered the scenarios irrelevant.
The security of an application is a continuous struggle between solid proactive controls and quality in SDLC versus human weakness and resource restrictions. As the pentester's experience confirms, unfortunatelly even in high-risk (e.g. banking) applications, developed by recognized vendors, the latter often wins - and we end up with critical vulnerabilities.
One of the primary reasons is lack of mechanisms enforcing secure code by default, as opposed to manual adding security per each function. Whenever the secure configuration is not default, there will almost inevitably be bugs, especially in complex systems.
I will pinpoint what should be taken into consideration in the architecture and design process of the application. I will show solutions that impose security in ways difficult to circumvent unintentionally by creative developers. I will also share with the audience the pentester's (=attacker's) perspective, and a few clever tricks that made the pentest
(=attack) painful, or just rendered the scenarios irrelevant.
4 andrii kudiurov - web application security 101Ievgenii Katsan
This document provides an overview of common web application security vulnerabilities and how to test for them. It covers:
1. Never trusting user input and how HTTP works.
2. Testing for misconfiguration issues, hidden options, forced navigation, mass parameter assignment, CSRF, injection flaws like XSS and SQLi, open redirect, path traversal, and DoS vulnerabilities.
3. Recommending automation tools like Dirbuster and BurpSuite to help find issues, but noting that context is important and automated scanners have limitations. More manual testing is needed.
This talk walks through the basics of web security without focussing too much on the particular tools that you choose. The concepts are universal, although most examples will be in Perl. We'll also look at various attack vectors (SQL Injection, XSS, CSRF, and more) and see how you can avoid them. Whether you're an experienced web developer (we all need reminding) or just starting out, this talk can help avoid being the next easy harvest of The Bad Guys.
This document summarizes common web application security vulnerabilities in Ruby on Rails such as SQL injection, cross-site scripting (XSS), cross-site request forgery (CSRF), mass assignment, and CVE-2012-2661. It provides examples of these vulnerabilities and discusses countermeasures like input sanitization, access control, CSRF tokens, whitelisting attributes, and upgrading Rails versions. The document concludes by recommending following Rails security best practices and resources for learning about securing Rails applications.
This document summarizes common web application vulnerabilities like cross-site scripting (XSS), SQL injection, and file uploads. It provides examples of each vulnerability and recommendations for mitigation strategies. For XSS, it recommends sanitizing input and escaping output. For SQL injection, it suggests using parameterized queries, stored procedures, and escaping strings. For file uploads, it advises validating file types, randomizing filenames, and restricting directory permissions. The document aims to help secure PHP web applications from these common risks.
The top 10 security issues in web applicationsDevnology
The top 10 security issues in web applications are:
1. Injection flaws such as SQL, OS, and LDAP injection.
2. Cross-site scripting (XSS) vulnerabilities that allow attackers to execute scripts in a victim's browser.
3. Broken authentication and session management, such as not logging users out properly or exposing session IDs.
4. Insecure direct object references where users can directly access files without authorization checks.
5. Cross-site request forgery (CSRF) that tricks a user into performing actions they did not intend.
6. Security misconfiguration of web or application servers.
7. Insecure cryptographic storage of passwords or sensitive data.
8
The document discusses various PHP security vulnerabilities like code injection, SQL injection, cross-site scripting (XSS), session hijacking, and remote code execution. It provides examples of each vulnerability and methods to prevent them, such as input validation, output encoding, secure session management, and restricting shell commands. The goal is to teach secure PHP programming practices to avoid security issues and defend against common attacks.
DDD17 - Web Applications Automated Security Testing in a Continuous Delivery...Fedir RYKHTIK
Slides from "Web Applications Automated Security Testing in a Continuous Delivery Pipeline" workshop, made during Drupal Developers Days 2017 at Seville, Spain
This document introduces Web Application Firewall (WAF) and discusses techniques for bypassing WAF protections, including SQL injection, cross-site scripting, file inclusion, HTTP parameter contamination, and HTTP pollution attacks. It provides examples of bypassing specific WAF vendors and open source WAFs like ModSecurity and PHPIDS. While WAFs can block some attacks, the document argues they cannot eliminate all vulnerabilities and proper secure coding is still needed. It concludes that WAFs may succeed or fail depending on configurations and imaginative attacks.
Gen Z and the marketplaces - let's translate their needsLaura Szabó
The product workshop focused on exploring the requirements of Generation Z in relation to marketplace dynamics. We delved into their specific needs, examined the specifics in their shopping preferences, and analyzed their preferred methods for accessing information and making purchases within a marketplace. Through the study of real-life cases , we tried to gain valuable insights into enhancing the marketplace experience for Generation Z.
The workshop was held on the DMA Conference in Vienna June 2024.
Drupal Security from Drupalcamp BratislavaGábor Hojtsy
Gábor Hojtsy presented on Drupal security at Drupalcamp Bratislava in 2010. He discussed common security risks like injection, cross-site scripting, authentication issues and how Drupal addresses them through secure APIs and modules. The Drupal security team works to ensure the security of Drupal core and contributed modules by finding and fixing vulnerabilities and educating developers on secure coding practices. While open source can increase scrutiny, it also multiplies eyes finding and addressing issues for more secure software.
OWASP Top 10 vs Drupal - OWASP Benelux 2012ZIONSECURITY
The document discusses securing Drupal against the OWASP Top 10 vulnerabilities. It provides examples of how vulnerabilities like SQL injection, XSS, session hijacking, insecure direct object references, CSRF, misconfiguration issues and failure to restrict URL access could occur in Drupal. It also explains the security measures Drupal has implemented, such as input filtering, form tokens, access control and encryption to address these risks.
Rails security best practices involve defending at multiple layers including the network, operating system, web server, web application, and database. The document outlines numerous vulnerabilities at the web application layer such as information leaks, session hijacking, SQL injection, mass assignment, unscoped finds, cross-site scripting (XSS), cross-site request forgery (CSRF), and denial-of-service attacks. It provides recommendations to address each vulnerability through secure coding practices and configuration in Rails.
All about web application security and common threats and how to counter measure these threats
The content of this presentation was derived from several notable Drupal SA team like Greg Knaddison, Khalid Baheyeldin, Heine Deelstra, and Dave Reid.
Special thanks to Greg's book "Cracking Drupal: A Drop in the Bucket".
This document discusses securing Drupal websites. It covers common Drupal attacks like XSS and SQL injection and recommends countermeasures like keeping software updated, following coding standards, sanitizing user input, and penetration testing. The document also provides an overview of securing the web server, PHP, and the Drupal codebase through permissions, input validation, and file uploads.
Gábor Hojtsy gave a presentation on doing Drupal security right. He discussed common web application security risks like SQL injection, cross-site scripting, and insecure direct object references. He explained how Drupal addresses these issues through features like input filtering, form tokens, and access control. Hojtsy emphasized that while Drupal provides secure APIs, developers must use them properly. He also discussed Drupal's open security team that works to find and fix vulnerabilities in Drupal core and contributed modules.
Gábor Hojtsy presented on Drupal security at Drupalcamp Bratislava. He discussed the top security risks for Drupal sites like insecure server configurations, weak passwords, and cross-site scripting vulnerabilities. Hojtsy explained the proper Drupal approaches to mitigate these risks, such as using strong passwords, keeping software updated, sanitizing user input, and leveraging Drupal's built-in security features like form tokens. He also covered the work of the Drupal security team to help ensure the core framework and contributed modules are secure.
Doing Drupal security right from Drupalcon LondonGábor Hojtsy
This document summarizes a presentation on doing Drupal security right. It discusses common security issues like SQL injection, cross-site scripting, authentication and session security. It provides the Drupal approach to addressing each issue through secure APIs and modules. It also discusses open source security in general and notes that Drupal security is supported by a volunteer team working to ensure the security of Drupal core and contributed projects.
Tips on Securing Drupal Sites - DrupalCamp Atlanta (DCA)cgmonroe
This is an updated version of this talk given at DrupalCamp Atlanta (DCA)
This presentation is an overview / case study of things learned by experiencing GDPR Security audits, DoS attacks, brute force login attacks, annoying robot crawlers, and hackers doing security probes.
The session will cover the following main topics with tips on how to protected against each of these.
An overview of security threats
Server Level Attacks
Code Level Attacks
User Access Attacks
Internal Attacks
Some suggestions on developing a security plan
People attending should come away with useful knowledge (modules, best practices, sites that help, front end tools and the like) that will help secure their sites.
The security of an application is a continuous struggle between solid proactive controls and quality in SDLC versus human weakness and resource restrictions. As the pentester's experience confirms, unfortunatelly even in high-risk (e.g. banking) applications, developed by recognized vendors, the latter often wins - and we end up with critical vulnerabilities.
One of the primary reasons is lack of mechanisms enforcing secure code by default, as opposed to manual adding security per each function. Whenever the secure configuration is not default, there will almost inevitably be bugs, especially in complex systems. I will pinpoint what should be taken into consideration in the architecture and design process of the application. I will show solutions that impose security in ways difficult to circumvent unintentionally by creative developers. I will also share with the audience the pentester's (=attacker's) perspective, and a few clever tricks that made the pentest (=attack) painful, or just rendered the scenarios irrelevant.
The security of an application is a continuous struggle between solid proactive controls and quality in SDLC versus human weakness and resource restrictions. As the pentester's experience confirms, unfortunatelly even in high-risk (e.g. banking) applications, developed by recognized vendors, the latter often wins - and we end up with critical vulnerabilities.
One of the primary reasons is lack of mechanisms enforcing secure code by default, as opposed to manual adding security per each function. Whenever the secure configuration is not default, there will almost inevitably be bugs, especially in complex systems.
I will pinpoint what should be taken into consideration in the architecture and design process of the application. I will show solutions that impose security in ways difficult to circumvent unintentionally by creative developers. I will also share with the audience the pentester's (=attacker's) perspective, and a few clever tricks that made the pentest
(=attack) painful, or just rendered the scenarios irrelevant.
4 andrii kudiurov - web application security 101Ievgenii Katsan
This document provides an overview of common web application security vulnerabilities and how to test for them. It covers:
1. Never trusting user input and how HTTP works.
2. Testing for misconfiguration issues, hidden options, forced navigation, mass parameter assignment, CSRF, injection flaws like XSS and SQLi, open redirect, path traversal, and DoS vulnerabilities.
3. Recommending automation tools like Dirbuster and BurpSuite to help find issues, but noting that context is important and automated scanners have limitations. More manual testing is needed.
This talk walks through the basics of web security without focussing too much on the particular tools that you choose. The concepts are universal, although most examples will be in Perl. We'll also look at various attack vectors (SQL Injection, XSS, CSRF, and more) and see how you can avoid them. Whether you're an experienced web developer (we all need reminding) or just starting out, this talk can help avoid being the next easy harvest of The Bad Guys.
This document summarizes common web application security vulnerabilities in Ruby on Rails such as SQL injection, cross-site scripting (XSS), cross-site request forgery (CSRF), mass assignment, and CVE-2012-2661. It provides examples of these vulnerabilities and discusses countermeasures like input sanitization, access control, CSRF tokens, whitelisting attributes, and upgrading Rails versions. The document concludes by recommending following Rails security best practices and resources for learning about securing Rails applications.
This document summarizes common web application vulnerabilities like cross-site scripting (XSS), SQL injection, and file uploads. It provides examples of each vulnerability and recommendations for mitigation strategies. For XSS, it recommends sanitizing input and escaping output. For SQL injection, it suggests using parameterized queries, stored procedures, and escaping strings. For file uploads, it advises validating file types, randomizing filenames, and restricting directory permissions. The document aims to help secure PHP web applications from these common risks.
The top 10 security issues in web applicationsDevnology
The top 10 security issues in web applications are:
1. Injection flaws such as SQL, OS, and LDAP injection.
2. Cross-site scripting (XSS) vulnerabilities that allow attackers to execute scripts in a victim's browser.
3. Broken authentication and session management, such as not logging users out properly or exposing session IDs.
4. Insecure direct object references where users can directly access files without authorization checks.
5. Cross-site request forgery (CSRF) that tricks a user into performing actions they did not intend.
6. Security misconfiguration of web or application servers.
7. Insecure cryptographic storage of passwords or sensitive data.
8
The document discusses various PHP security vulnerabilities like code injection, SQL injection, cross-site scripting (XSS), session hijacking, and remote code execution. It provides examples of each vulnerability and methods to prevent them, such as input validation, output encoding, secure session management, and restricting shell commands. The goal is to teach secure PHP programming practices to avoid security issues and defend against common attacks.
DDD17 - Web Applications Automated Security Testing in a Continuous Delivery...Fedir RYKHTIK
Slides from "Web Applications Automated Security Testing in a Continuous Delivery Pipeline" workshop, made during Drupal Developers Days 2017 at Seville, Spain
This document introduces Web Application Firewall (WAF) and discusses techniques for bypassing WAF protections, including SQL injection, cross-site scripting, file inclusion, HTTP parameter contamination, and HTTP pollution attacks. It provides examples of bypassing specific WAF vendors and open source WAFs like ModSecurity and PHPIDS. While WAFs can block some attacks, the document argues they cannot eliminate all vulnerabilities and proper secure coding is still needed. It concludes that WAFs may succeed or fail depending on configurations and imaginative attacks.
Similar to Drupal campleuven: Secure Drupal Development (20)
Gen Z and the marketplaces - let's translate their needsLaura Szabó
The product workshop focused on exploring the requirements of Generation Z in relation to marketplace dynamics. We delved into their specific needs, examined the specifics in their shopping preferences, and analyzed their preferred methods for accessing information and making purchases within a marketplace. Through the study of real-life cases , we tried to gain valuable insights into enhancing the marketplace experience for Generation Z.
The workshop was held on the DMA Conference in Vienna June 2024.
Instagram has become one of the most popular social media platforms, allowing people to share photos, videos, and stories with their followers. Sometimes, though, you might want to view someone's story without them knowing.
Understanding User Behavior with Google Analytics.pdfSEO Article Boost
Unlocking the full potential of Google Analytics is crucial for understanding and optimizing your website’s performance. This guide dives deep into the essential aspects of Google Analytics, from analyzing traffic sources to understanding user demographics and tracking user engagement.
Traffic Sources Analysis:
Discover where your website traffic originates. By examining the Acquisition section, you can identify whether visitors come from organic search, paid campaigns, direct visits, social media, or referral links. This knowledge helps in refining marketing strategies and optimizing resource allocation.
User Demographics Insights:
Gain a comprehensive view of your audience by exploring demographic data in the Audience section. Understand age, gender, and interests to tailor your marketing strategies effectively. Leverage this information to create personalized content and improve user engagement and conversion rates.
Tracking User Engagement:
Learn how to measure user interaction with your site through key metrics like bounce rate, average session duration, and pages per session. Enhance user experience by analyzing engagement metrics and implementing strategies to keep visitors engaged.
Conversion Rate Optimization:
Understand the importance of conversion rates and how to track them using Google Analytics. Set up Goals, analyze conversion funnels, segment your audience, and employ A/B testing to optimize your website for higher conversions. Utilize ecommerce tracking and multi-channel funnels for a detailed view of your sales performance and marketing channel contributions.
Custom Reports and Dashboards:
Create custom reports and dashboards to visualize and interpret data relevant to your business goals. Use advanced filters, segments, and visualization options to gain deeper insights. Incorporate custom dimensions and metrics for tailored data analysis. Integrate external data sources to enrich your analytics and make well-informed decisions.
This guide is designed to help you harness the power of Google Analytics for making data-driven decisions that enhance website performance and achieve your digital marketing objectives. Whether you are looking to improve SEO, refine your social media strategy, or boost conversion rates, understanding and utilizing Google Analytics is essential for your success.
APNIC Foundation, presented by Ellisha Heppner at the PNG DNS Forum 2024APNIC
Ellisha Heppner, Grant Management Lead, presented an update on APNIC Foundation to the PNG DNS Forum held from 6 to 10 May, 2024 in Port Moresby, Papua New Guinea.
4. MANY EYES MAKE FOR SECURE CODE
IS OPEN SOURCE SECURE?
- Security by obscurity
- Open code does not make it easier for hackers
- Open Source makes people look at it
- Popularity gets more eyes and more peer-reviews
• Bad open-source software as bad
• as bad private software.
5. VULNERABILITIES
OWASP
- Injection
- Cross Site Scripting - XSS
- Broken Authentication and Session Management
- Cross Site Request Forgery - CSRF
- Security Misconfguration
- Failure to Restrict URL Access
- Access bypas
7. IS DRUPAL SECURE?
- Safe by design (Core and API)
- Security Team
- Highly organised
- Documented process for Security Advisories and Updates
- Thousands of maintainers, users and experts
- Support: Drupal 6/7, Core & Contributed Modules
20. CONTRIBUTED MODULES
Quality assurance
- Usage
- Number of open issues
- Closed/Open ratio
- Response time
Good quality usually means good security
Manual code reviews for less used modules
21. UPDATES
Always stay up to date
- Keep up with latest security releases
Update Workflow
- Hacked module + diff
- Drush up
22. PATCHES
Contrib patches
Read the entire issue
Commit custom patches
Help out
Feedback from other users (maintainers)
Patch might get commited
Patch management
Move module to patched
Create a patches.txt
Keep patches
26. SQL INJECTION
"SELECT * FROM user WHERE name = '$name'"
"SELECT * FROM user WHERE name = 'Robert'; DROP TABLE students;'"
h4p://xkcd.com/327/
27. SQL INJECTION
Placeholders
db_query(“SELECT * FROM users WHERE name = :user”, array(':user' => $user);
Dynamic Queries
$query = db_select('user', 'u')
->fields('u')
->where('name', $user)
->execute();
28. XSS (cross site scripting)
EXECUTING ABRITRARY JAVASCRIPT CODE ON THE PAGE
29. XSS (cross site scripting)
User Input
Title
Body
Log message
Url
Post
User-Agent
Headers
30. XSS (cross site scripting)
Validate forms
User input should never contain javascript
Form api
Never use $_POST variables
$form_state['values']
Form caching
31. XSS (cross site scripting)
Input formats
Never use full_html
Filter Functions
check_url()
check_plain()
check_markup()
filter_xss()
32. XSS (cross site scripting)
h4p://drupalscout.com/knowledge-‐base/drupal-‐text-‐filtering-‐cheat-‐sheet-‐drupal-‐6
33. XSS (cross site scripting)
Functions
t()
l()
drupal_set_title()
@var => plain text
%var => plain text
!var => full html!
34. CSRF (cross site request forgery)
Taking action without confirming intent
<a href=”/delete/user/1”>Delete user 1</a>
Image Tag
<img src=”/delete/user/1”>
A hacker posts a comment to the administrator.
When the administrator views the image, user 1 gets deleted
37. ACCESS BYPASS
View content a user is not supposed to
$query = db_select('node', 'n')->fields('n');
Also shows nodes that user doesn't have acces to
$query->addTag('node_access')
Rewrite the query based on the node_access table
38. ACCESS BYPASS
Bad custom caching
Administrator visits a block listing nodes.
The block gets cached
The cached block with all nodes is shown to the anonymous user
Add role id to custom caching
39. ACCESS BYPASS
Rabbit_hole module
Rabbit Hole is a module that adds the ability to control what should happen
when an entity is being viewed at its own page.
Page manager can do the same.
Field access
$form['#access'] = custom_access_callback();
Menu access
$item['access callback'] = 'custom_access_callback',
40. CORRECT USE OF API
Form API
Validation
Form state
Drupal_valid_token
DB API
db_select, db_insert, placeholders
$query->addTag(‘node_access’);
Filter
check_url, check_plain, check_markup, filter_xss, …
t(), l(), drupal_set_title(), …
44. PERMISSIONS
Permission management
If Joe from advertising can give the full html filter format to anonymous user,
don't bother to think about security
Split up permissions
The default permissions don't cover every use case
48. CHECKLIST
Never use
full_html
Php filter
Permissions
Trusted users only
Split up permissions
API
Preprocess functions
check_plain, filter_xss
DB API
Form API
Tokens
Menu/Node Access
51. FURTHER READING
Books
Cracking Drupal !!
Pro Drupal Development
Online
https://drupal.org/writing-secure-code
https://drupal.org/node/360052
http://munich2012.drupal.org/program/sessions/think-hacker-secure-drupal-code.html
http://drupalscout.com/knowledge-base
Video
How to avoid All your base are belong to us (drupalcon Denver)