Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Pygoat - Learn Django security the hard way

Pygoat - Learn Django security the hard way

Learn to secure your Django apps by attacking (and then securing) Pygoat - An intentionally vulnerable Python Django application. Explore the OWASP top 10 vulnerabilities and understand how to mitigate them from Django apps.

Adarsh D

July 21, 2023
Tweet

More Decks by Adarsh D

Other Decks in Programming

Transcript

  1. PyGoat
    Learn Django security
    the hard way
    Adarsh Divakaran
    Lead Engineer at Digievo
    Thameem Karakkoth
    Product Engineer at Strollby - UST

    View full-size slide

  2. Web Application Security
    Web application security encompasses a range of measures, technologies, or
    approaches aimed at safeguarding web servers, web applications, and web
    services, including APIs, against potential attacks from online threats. Its
    significance lies in safeguarding valuable data, customers, and organizations
    from data breaches, disruptions to business operations, or any adverse
    consequences stemming from cyber criminal activities.

    View full-size slide

  3. Web Application Security
    ● Based on an analysis of 14 million websites, SiteLock reports that
    websites currently experience an average of 172 attacks every day, and
    are visited by bots approximately 2,306 times a week.
    ● Malicious bots represent over 60% of all bot traffic
    ● Cyberattacks cost small and medium-Sized Businesses $25k annually on
    average
    ● The volume of threats are doubling year over year
    Source: https://www.sitelock.com/resources/security-report

    View full-size slide

  4. OWASP
    The Open Worldwide Application Security Project (OWASP) is an online
    community that produces freely-available articles, methodologies,
    documentation, tools, and technologies in the field of web application security
    OWASP provides tools and resources for security researchers as well as
    developers to test and fortify their applications.

    View full-size slide

  5. OWASP Top 10
    The OWASP Top 10 is a regularly-updated report outlining security concerns
    for web application security, focusing on the 10 most critical risks. The report
    is put together by a team of security experts from all over the world.

    View full-size slide

  6. The Pygoat Project
    Pygoat is an intentionally vulnerable Python Django application that can be
    used to learn to secure our Django apps.
    Pygoat contains labs to learn about and exploit the OWASP top 10
    vulnerabilities.

    View full-size slide

  7. A1 Broken Access Control
    Access control, sometimes called authorization, is how a web application
    grants access to content and functions to some users and not others. These
    checks are performed after authentication, and govern what ‘authorized’ users
    are allowed to do.

    View full-size slide

  8. PyGoat Lab 1

    View full-size slide

  9. Vulnerable Code

    View full-size slide

  10. Mitigation
    ● Except for public resources, deny by default.
    ● Implement access control mechanisms once and re-use them throughout the
    application, including minimizing Cross-Origin Resource Sharing (CORS) usage.
    ● Model access controls should enforce record ownership rather than accepting that the
    user can create, read, update, or delete any record.
    ● Unique application business limit requirements should be enforced by domain models.
    ● Disable web server directory listing and ensure file metadata (e.g., .git) and backup files
    are not present within web roots.
    ● Log access control failures, alert admins when appropriate (e.g., repeated failures).
    ● Rate limit API and controller access to minimize the harm from automated attack
    tooling.
    ● Stateful session identifiers should be invalidated on the server after logout. Stateless
    JWT tokens should rather be short-lived so that the window of opportunity for an
    attacker is minimized. For longer lived JWTs it's highly recommended to follow the
    OAuth standards to revoke access.

    View full-size slide

  11. A2 Cryptographic Failures
    Cryptographic failure is the root cause of Sensitive Data Exposure.
    Enumerations (CWEs) included are CWE-259: Use of Hard-coded Password,
    CWE-327: Broken or Risky Crypto Algorithm, and CWE-331 Insufficient Entropy.

    View full-size slide

  12. Mitigation
    ● Classify data processed, stored, or transmitted by an application. Identify which
    data is sensitive according to privacy laws, regulatory requirements, or business
    needs.
    ● Don't store sensitive data unnecessarily. Discard it as soon as possible or use
    PCI DSS compliant tokenization or even truncation. Data that is not retained
    cannot be stolen.
    ● Make sure to encrypt all sensitive data at rest.
    ● Ensure up-to-date and strong standard algorithms, protocols, and keys are in
    place; use proper key management.
    ● Encrypt all data in transit with secure protocols such as TLS with forward secrecy
    (FS) ciphers, cipher prioritization by the server, and secure parameters. Enforce
    encryption using directives like HTTP Strict Transport Security (HSTS).
    ● Disable caching for response that contain sensitive data.

    View full-size slide

  13. A3: Injection
    Injection happens when an attacker sneaks in untrusted data and tricks the
    interpreter into doing things it shouldn't, like running unintended commands
    or accessing unauthorized data.
    Eg: SQL, NoSQL, OS command, Object Relational Mapping (ORM), LDAP, and
    Expression Language (EL) or Object Graph Navigation Library (OGNL) injection

    View full-size slide

  14. Pygoat Lab 1

    View full-size slide

  15. Vulnerable Code

    View full-size slide

  16. Pygoat Lab 2

    View full-size slide

  17. Vulnerable Code

    View full-size slide

  18. Mitigation
    ● The preferred option is to use a safe API, which avoids using the
    interpreter entirely, provides a parameterized interface, or migrates to
    Object Relational Mapping Tools (ORMs).
    ● Use positive server-side input validation. This is not a complete defense
    as many applications require special characters, such as text areas or
    APIs for mobile applications.
    ● For any residual dynamic queries, escape special characters using the
    specific escape syntax for that interpreter.
    ● Use LIMIT and other SQL controls within queries to prevent mass
    disclosure of records in case of SQL injection.

    View full-size slide

  19. A4: Insecure Design
    Insecure design is a type of flaw that can sit in the background of everything
    you do. This vulnerability relates to how you as a developer design your
    programs, architect solutions, and employ security practices such as threat
    modeling

    View full-size slide

  20. Pygoat lab objective

    View full-size slide

  21. This website is giving everyone free tickets ( upto 5 per person ). And the
    movie will be public when all the tickets will be sold.
    The ticket generating system is inherently secure, limiting users to obtain a
    maximum of 5 free tickets. However, a significant design flaw exists – multiple
    accounts can be created to acquire an unlimited number of tickets. For
    instance, in this specific scenario where 60 tickets are required, one could
    easily exploit the system by creating just 12 accounts, claiming 5 tickets from
    each.

    View full-size slide

  22. Mitigation
    ● Establish and use a secure development lifecycle with AppSec
    professionals to help evaluate and design security and privacy-related
    controls
    ● Establish and use a library of secure design patterns or paved road
    ready to use components
    ● Use threat modeling for critical authentication, access control, business
    logic, and key flows
    ● Integrate security language and controls into user stories
    ● Integrate plausibility checks at each tier of your application (from
    frontend to backend)

    View full-size slide

  23. Mitigation
    ● Write unit and integration tests to validate that all critical flows are
    resistant to the threat model. Compile use-cases and misuse-cases for
    each tier of your application.
    ● Segregate tier layers on the system and network layers depending on the
    exposure and protection needs
    ● Segregate tenants robustly by design throughout all tiers
    ● Limit resource consumption by user or service

    View full-size slide

  24. A5: Security Misconfiguration
    The application might be vulnerable if the application is:
    ● Missing appropriate security hardening across any part of the application stack or
    improperly configured permissions on cloud services.
    ● Unnecessary features are enabled or installed (e.g., unnecessary ports, services,
    pages, accounts, or privileges).
    ● Default accounts and their passwords are still enabled and unchanged.
    ● Error handling reveals stack traces or other overly informative error messages to
    users.

    View full-size slide

  25. Pygoat Lab 1

    View full-size slide

  26. Mitigation
    This case is an example of Security through obscurity.
    ● Raw inputs from front end should not be trusted
    ● If using headers to enforce access controls, should use encryption
    mechanism to preserve the secrecy of the key.

    View full-size slide

  27. Pygoat Lab 2
    Objective:
    One of the features of having DEBUG=True is dumping lots of metadata from
    your environment, including the whole settings.py configurations, when a
    exception occurs.
    Can u trigger a 500 error and get the SENSITIVE_DATA ?

    View full-size slide

  28. Mitigation
    Django debug mode was enabled. This can lead to tracebacks, error messages
    and env variables being displayed to users.
    In a publicly accessible environment, Debug mode should be disabled using
    the below Django setting (settings.py):
    DEBUG = False

    View full-size slide

  29. Security Misconfiguration - Prevention
    ● A repeatable hardening process makes it fast and easy to deploy another environment
    that is appropriately locked down. This process should be automated to minimize the
    effort required to set up a new secure environment.
    ● A minimal platform without any unnecessary features, components, documentation, and
    samples. Remove or do not install unused features and frameworks.
    ● A task to review and update the configurations appropriate to all security notes, updates,
    and patches as part of the patch management process. Review cloud storage
    permissions (e.g., S3 bucket permissions).
    ● An automated process to verify the effectiveness of the configurations and settings in all
    environments.

    View full-size slide

  30. A6: Vulnerable and Outdated Components
    The application might be vulnerable:
    ● If the software used is vulnerable, unsupported, or out of date. This includes the OS,
    web/application server, database management system (DBMS), applications, APIs and
    all components, runtime environments, and libraries.
    ● If you do not scan for vulnerabilities regularly and subscribe to security bulletins
    related to the components you use.
    ● If you do not fix or upgrade the underlying platform, frameworks, and dependencies in
    a risk-based, timely fashion. This commonly happens in environments when patching is
    a monthly or quarterly task under change control, leaving organizations open to days
    or months of unnecessary exposure to fixed vulnerabilities.

    View full-size slide

  31. Pygoat Lab - Objective
    This lab helps us to understand why components with known vulnerabilities
    can be a serious issue.
    The user on accessing the lab is provided with a feature to convert yaml files
    into json objects. A yaml file needs to be chosen and uploaded to get the json
    data.
    The app uses pyyaml 5.1 which is vulnerable to code execution.

    View full-size slide

  32. Pygoat Lab
    We can craft a yaml as shown below to execute code on the server

    View full-size slide

  33. Mitigation
    ● Remove unused dependencies, unnecessary features, components, files, and documentation.
    ● Continuously inventory the versions of both client-side and server-side components (e.g.,
    frameworks, libraries) and their dependencies using tools like versions, OWASP Dependency
    Check, retire.js, etc. Continuously monitor sources like Common Vulnerability and Exposures
    (CVE) and National Vulnerability Database (NVD) for vulnerabilities in the components. Use
    software composition analysis tools to automate the process. Subscribe to email alerts for
    security vulnerabilities related to components you use.
    ● Only obtain components from official sources over secure links. Prefer signed packages to
    reduce the chance of including a modified, malicious component (See A08:2021-Software and
    Data Integrity Failures).

    View full-size slide

  34. A7: Identification and Authentication Failures
    There are times when the way applications handle passwords and user logins
    is done incorrectly. This can let attackers get access to passwords, keys, or
    tokens, or take advantage of other mistakes in how the app works to pretend
    to be someone else, either for a little while or forever.

    View full-size slide

  35. Pygoat Lab - Objective
    The main aim of this lab is to login as admin, for that we need to exploit the
    lack of rate limiting feature in the otp verification flow. You can see that the
    otp is only of 3 digit(for demo purposes) and the application doesn’t have any
    captcha (To disallow any automated scripts or bots) or any restrictions on the
    number of tries for the otp.

    View full-size slide

  36. Mitigation
    ● Where possible, implement multi-factor authentication to prevent automated
    credential stuffing, brute force, and stolen credential reuse attacks.
    ● Do not ship or deploy with any default credentials, particularly for admin users.
    ● Implement weak password checks, such as testing new or changed passwords against
    the top 10,000 worst passwords list.
    ● Ensure registration, credential recovery, and API pathways are hardened against
    account enumeration attacks by using the same messages for all outcomes.
    ● Limit or increasingly delay failed login attempts, but be careful not to create a denial of
    service scenario. Log all failures and alert administrators when credential stuffing,
    brute force, or other attacks are detected.

    View full-size slide

  37. A8 Software and Data Integrity Failures
    Software and data integrity failures relate to code and infrastructure that does not protect
    against integrity violations. An example of this is where an application relies upon plugins,
    libraries, or modules from untrusted sources, repositories, and content delivery networks
    (CDNs).
    Eg: Insecure Deserialization
    Applications and APIs will be vulnerable if they deserialize hostile or tampered objects
    supplied by an attacker. This can result in two primary types of attacks:
    ● Object and data structure related attacks where the attacker modifies application logic
    or achieves arbitrary remote code execution if there are classes available to the
    application that can change behavior during or after deserialization.
    ● Typical data tampering attacks such as access-control-related attacks where existing
    data structures are used but the content is changed.

    View full-size slide

  38. Vulnerability
    Page is vulnerable to XSS.
    Name is directly printed from the url param.
    If we specify name value as:
    user+document.getElementById("download_link").setAttribute("href"%<br/>2C"%2Fstatic%2Ffake.txt")%3B<%2Fscript>user+<script>document.getElement<br/>ById("download_link").setAttribute("href"%2C"%2Fstatic%2Ffake.txt")%3B<%2F<br/>script><br/>The download url is modified and user may download an arbitrary file by<br/>trusting the domain<br/>

    View full-size slide

  39. Mitigation
    For the demonstrated vulnerability, XSS is used to redirect user to a fake file.
    As a user we should always cross-check signatures for verification of Data
    Integrity. Checksums should be provided for downloads so that it can be cross
    checked from user end.

    View full-size slide

  40. Mitigation
    ● Use digital signatures or similar mechanisms to verify the software or data is from the expected
    source and has not been altered.
    ● Ensure libraries and dependencies, are consuming trusted repositories. If you have a higher
    risk profile, consider hosting an internal known-good repository that's vetted.
    ● Ensure that a software supply chain security tool, such as OWASP Dependency Check or OWASP
    CycloneDX, is used to verify that components do not contain known vulnerabilities
    ● Ensure that your CI/CD pipeline has proper segregation, configuration, and access control to
    ensure the integrity of the code flowing through the build and deploy processes.
    ● Ensure that unsigned or unencrypted serialized data is not sent to untrusted clients without
    some form of integrity check or digital signature to detect tampering or replay of the serialized
    data

    View full-size slide

  41. A09: Security Logging and Monitoring Failures
    This category is to help detect, escalate, and respond to active breaches. Without logging and monitoring,
    breaches cannot be detected. Insufficient logging, detection, monitoring, and active response occurs any time:
    ● Auditable events, such as logins, failed logins, and high-value transactions, are not logged.
    ● Warnings and errors generate no, inadequate, or unclear log messages.
    ● Logs of applications and APIs are not monitored for suspicious activity.
    ● Appropriate alerting thresholds and response escalation processes are not in place or effective.
    ● Penetration testing and scans by dynamic application security testing (DAST) tools (such as OWASP ZAP) do
    not trigger alerts.
    ● The application cannot detect, escalate, or alert for active attacks in real-time or near real-time.

    View full-size slide

  42. Mitigation
    Ensure all login, access control, and server-side input validation failures can be logged with sufficient
    user context to identify suspicious or malicious accounts and held for enough time to allow delayed
    forensic analysis.
    Ensure that logs are generated in a format that log management solutions can easily consume.
    Ensure log data is encoded correctly to prevent injections or attacks on the logging or monitoring
    systems.
    Ensure high-value transactions have an audit trail with integrity controls to prevent tampering or
    deletion, such as append-only database tables or similar.
    DevSecOps teams should establish effective monitoring and alerting such that suspicious activities
    are detected and responded to quickly.

    View full-size slide

  43. A10: Server Side Request Forgery (SSRF)
    ● SSRF flaws occur whenever a web application is fetching a remote resource without
    validating the user-supplied URL. It allows an attacker to coerce the application to
    send a crafted request to an unexpected destination.
    Sample usages for remote url fetching: DNS Checkers, URL previews on social media
    ● Common attacks: Attacks on internal services/files, Attack on external URLs (DoS)

    View full-size slide

  44. Pygoat - SSRF Lab

    View full-size slide

  45. Vulnerable Code

    View full-size slide

  46. Mitigation
    From Application layer:
    ● Sanitize and validate all client-supplied input data
    ● Enforce the URL schema, port, and destination with a positive allow list
    ● Do not send raw responses to clients

    View full-size slide

  47. References
    OWASP Top 10:
    https://owasp.org/Top10/
    Pygoat Project and Demos:
    https://github.com/adeyosemanputra/pygoat
    https://www.youtube.com/watch?v=k_C5bNF1VGs

    View full-size slide

  48. Learning resources
    Hacksplaining: https://www.hacksplaining.com/owasp
    Web Security Academy: https://portswigger.net/web-security
    Owasp Cheatsheets: https://cheatsheetseries.owasp.org/IndexTopTen.html

    View full-size slide

  49. Thameem Karakkoth
    Adarsh Divakaran
    Thank You
    adarsh-d
    adarshd905
    thameem-karakkoth
    thameemk

    View full-size slide