## Find security vulnerabilities through code review Klaus Purer, [jobiqo.com](https://www.jobiqo.com) [drupal.org/u/klausi](https://www.drupal.org/u/klausi) <p> <a href="https://mastodon.social/@klausi"> <svg class="svg-icon" viewBox="0 0 216.4144 232.00976"> <path fill="#2b90d9" d="M211.80734 139.0875c-3.18125 16.36625-28.4925 34.2775-57.5625 37.74875-15.15875 1.80875-30.08375 3.47125-45.99875 2.74125-26.0275-1.1925-46.565-6.2125-46.565-6.2125 0 2.53375.15625 4.94625.46875 7.2025 3.38375 25.68625 25.47 27.225 46.39125 27.9425 21.11625.7225 39.91875-5.20625 39.91875-5.20625l.8675 19.09s-14.77 7.93125-41.08125 9.39c-14.50875.7975-32.52375-.365-53.50625-5.91875C9.23234 213.82 1.40609 165.31125.20859 116.09125c-.365-14.61375-.14-28.39375-.14-39.91875 0-50.33 32.97625-65.0825 32.97625-65.0825C49.67234 3.45375 78.20359.2425 107.86484 0h.72875c29.66125.2425 58.21125 3.45375 74.8375 11.09 0 0 32.975 14.7525 32.975 65.0825 0 0 .41375 37.13375-4.59875 62.915"/> <path fill="#fff" d="M177.50984 80.077v60.94125h-24.14375v-59.15c0-12.46875-5.24625-18.7975-15.74-18.7975-11.6025 0-17.4175 7.5075-17.4175 22.3525v32.37625H96.20734V85.42325c0-14.845-5.81625-22.3525-17.41875-22.3525-10.49375 0-15.74 6.32875-15.74 18.7975v59.15H38.90484V80.077c0-12.455 3.17125-22.3525 9.54125-29.675 6.56875-7.3225 15.17125-11.07625 25.85-11.07625 12.355 0 21.71125 4.74875 27.8975 14.2475l6.01375 10.08125 6.015-10.08125c6.185-9.49875 15.54125-14.2475 27.8975-14.2475 10.6775 0 19.28 3.75375 25.85 11.07625 6.36875 7.3225 9.54 17.22 9.54 29.675"/> </svg> klausi@mastodon.social </a> </p> <a href="https://twitter.com/_klausi_"> <svg class="svg-icon" viewBox="0 0 400 400"><defs><style>.cls-1{fill:none;}.cls-2{fill:#1da1f2;}</style></defs><title>Twitter_Logo_Blue</title><rect class="cls-1" width="400" height="400"/><path class="cls-2" d="M153.62,301.59c94.34,0,145.94-78.16,145.94-145.94,0-2.22,0-4.43-.15-6.63A104.36,104.36,0,0,0,325,122.47a102.38,102.38,0,0,1-29.46,8.07,51.47,51.47,0,0,0,22.55-28.37,102.79,102.79,0,0,1-32.57,12.45,51.34,51.34,0,0,0-87.41,46.78A145.62,145.62,0,0,1,92.4,107.81a51.33,51.33,0,0,0,15.88,68.47A50.91,50.91,0,0,1,85,169.86c0,.21,0,.43,0,.65a51.31,51.31,0,0,0,41.15,50.28,51.21,51.21,0,0,1-23.16.88,51.35,51.35,0,0,0,47.92,35.62,102.92,102.92,0,0,1-63.7,22A104.41,104.41,0,0,1,75,278.55a145.21,145.21,0,0,0,78.62,23"/></svg> twitter.com/_klausi_ </a> Drupalcon Amsterdam 2019 Note: * I work for jobiqo, a job board software provider that is using Drupal. I have been a Drupal developer for more than 11 years. * I have reviewed more than 1000 modules in the security advisory coverage queue * I was a member of the Drupal Security Team * I specialize in code review and correct Drupal API usage.

Goals of code review

• Find problems before they hit production
• Identify vulnerabilities before they get exploited
• Knowledge transfer from reviewer feedback
• Save cost by preventing problems

## Drupal 8 module layout <pre> pants +-- src | +-- PantsController.php +-- pants.install +-- pants.links.menu.yml +-- pants.module +-- pants.routing.yml +-- pants.services.yml +-- pants.token.inc +-- pants.html.twig </pre> Note: * This is a typical Drupal 8 module layout on the file system * The routing and the module files are the places you want to start reviewing * Controllers and services are interesting next * Then check output in Twig template files * Eventually read through all code of the module (if feasible)

## Attack entry point: Routing <pre> pants +-- src | +-- PantsController.php +-- pants.install +-- pants.links.menu.yml +-- pants.module <strong>+-- pants.routing.yml</strong> +-- pants.services.yml +-- pants.token.inc </pre> Note: * Let's start looking at the attack entry point of Routing * "pants" is just an example module name here * Incoming requests are handled here and forwarded to controllers or forms * An attacker will try to craft requests that bypass security protections * This is not the only way to exploit weaknesses in a module, but one of the most obvious ones.

## Access Bypass in a route<!-- .element: class="fragment" --> pants.routing.yml ```yml pants.admin: path: '/admin/pants' defaults: _form: '\Drupal\pants\AdminForm' requirements: _permission: 'access content' options: _admin_route: TRUE ``` The permission "access content" is probably not correct for an admin page!<!-- .element: class="fragment" --> [OWASP A5-Broken Access Control](https://www.owasp.org/index.php/Top_10-2017_A5-Broken_Access_Control)<!-- .element: class="fragment" --> Note: * _permission should be something like "administer pants" or similar * The Open Web Application Security Project (OWASP) has a very good classification of vulnerabilities * This would qualify as Broken Access Control * It ranks 5th on the top 10 vulnerabilities they identified in 2017

## Access Bypass in a route (2) pants.routing.yml ```yml pants.admin: path: '/admin/pants' defaults: _form: '\Drupal\pants\AdminForm' requirements: _access: 'TRUE' options: _admin_route: TRUE ``` Really dangerous, any attacker can access this admin path! Note: * Similar example as before: access control not set up correctly * Maybe a developer just allowed any access during development and forgot to change it * Always verify that the route requirements for access are correct

## CSRF in a route<!-- .element: class="fragment" --> pants.routing.yml ```yml pants.delete: path: '/pants/delete/{pants}' defaults: _controller: '\Drupal\pants\DeleteController::delete' requirements: _permission: 'delete pants' ``` src/DeleteController.php ```php class DeleteController extends ControllerBase { public function delete(Pants $pants) { $pants->delete(); return ['#markup' => 'Pants deleted successfully!']; } } ``` Note: * Example looks correct on first sight * The correct permission is used * User intent is not verified at any point

## Cross Site Request Forgery (CSRF) An attacker tricks you to visit her HTML page: ```html <img src="https://yourdrupal.org/pants/delete/5"> ``` 1. Your browser thinks this is an image and fetches it 2. It sends your session cookie along 3. The Pants delete controller executes 4. Pants 5 are deleted behind your back! Solution: confirmation forms or CSRF tokens in the URL/request Note: * Browsers are starting to block 3rd party cookies, so the img exploit will be mitigated a bit * An attacker can still trick you into clicking a vulnerable link, so CSRF remains * Drupal 8 has some help in the routing system with _csrf_token * Whenever you see a controller performing any data changing actions then there must be a confirmation form or _csrf_token.

## Using CSRF tokens pants.routing.yml ```yml pants.delete: path: '/pants/delete/{pants}' defaults: _controller: '\Drupal\pants\DeleteController::delete' requirements: _permission: 'delete pants' _csrf_token: 'TRUE' ``` Generating a URL/link ```php $url = Url::fromRoute('pants.delete', ['pants' => 5]); ``` <pre> /pants/delete/5?token=g_AGjC3tJsUhAO7Gfcfw9m94NollCAIxeMR69PQ7Qo0 </pre> Note: * The token in the URL is created from the session of the current user * cannot be guessed by an attacker * The routing system validates _csrf_token * Access is denied if the token is missing or invalid * Use case: when confirmation forms would downgrade usability * Example: Deleting a shortcut link in Drupal core * If clicked by accident a deleted shortcut is not that bad. * Use forms and confirmation forms per default for changing data

## Drupal 7: access bypass Wrong permission in hook_menu() ```php function pants_menu() { $items['admin/pants'] = array( 'title' => 'Pants', 'page callback' => 'drupal_get_form', 'page arguments' => array('pants_admin_form'), 'access arguments' => array('access content'), ); return $items; } ``` Note: * In Drupal 7 routing works differently, scenario is the same

## Drupal 7: access bypass (2) No access control at all in hook_menu() ```php function pants_menu() { $items['admin/pants'] = array( 'title' => 'Pants', 'page callback' => 'drupal_get_form', 'page arguments' => array('pants_admin_form'), 'access callback' => TRUE, ); return $items; } ``` Note: * You see how the routing access features also existed in Drupal 7 * Same considerations apply: no menu path should be unproteced! * Use a code comment in cases where open access is required to let your reviewer know why!

## Drupal 7: CSRF CSRF in hook_menu() ```php function pants_menu() { $items['admin/delete/%'] = array( 'title' => 'Delete pants', 'page callback' => 'pants_delete', 'page arguments' => array(2), 'access arguments' => array('delete pants'), ); return $items; } function pants_delete($pant_id) { db_delete('pants')->condition('id', $pant_id)->execute(); } ``` Note: * Unfortunately there is no built-in CSRF protection as in Drupal 8 * Again: use confirmation forms or CSRF tokens * You need to do CSRF token validation yourself in your page callback * Explain that in code comments to your reviewer

## Attack entry points summarized * Drupal 8: * routing.yml files * controllers and forms in src * Drupal 7: * hook_menu() in module files * page callbacks in module/inc files Check for Access Bypass and CSRF there! Note:

## SQL injection<!-- .element: class="fragment" --> ```php public function getLogItemsSinceTimestamp($timestamp) { $type = self::LOGGER_CHANNEL_NAME; $query = $this->database->select('watchdog', 'w'); $query->fields('w', [ 'wid', ]); $query->where("w.timestamp > $timestamp AND w.type = '$type'"); return $query->execute()->fetchCol(); } ``` Never concatenate variables into SQL strings!<!-- .element: class="fragment" --> [OWASP A1-Injection](https://www.owasp.org/index.php/Top_10-2017_A1-Injection)<!-- .element: class="fragment" --> Note: * the where clause might actually be a bit hard to exploit here. * If $timestamp is attacker controlled they can try to inject subqueries * OWASP qualifies this as the number 1 vulnerability in their top 10 * SQL injection in Drupal often means Remote Code Execution capabilities for an attacker * Drupal caches route callbacks in the database, an attacker could overwrite that with SQL injection * Injection happens at the boundary of systems, where data and instructions are mixed * The receiving system (database) cannot distinguish and the built query string what is a safe part of the instructions and what is data injected by an attacker.

## Correct SQL placeholders ```php public function getLogItemsSinceTimestamp($timestamp) { $type = self::LOGGER_CHANNEL_NAME; $query = $this->database->select('watchdog', 'w'); $query->fields('w', [ 'wid', ]); $query->condition('w.timestamp', $timestamp, '>'); $query->condition('w.type', $type, '='); return $query->execute()->fetchCol(); } ``` Note: * Use the Drupal database API correctly with placeholders for the user provided data * It will then escape all provided data correctly so that it cannot mix with query commands

## Shell injection<!-- .element: class="fragment" --> ```php function recruiter_job_pdf_content_extract($url) { $tika_lib_path = variable_get( 'recruiter_job_pdf_content_tika_lib_path', '/opt/tika/tika-app.jar' ); // Parse PDF using Apache Tika and output as html. $cmd = 'java -jar ' . $tika_lib_path . ' -h -eUTF-8 ' . $url; $parsed = shell_exec($cmd); return parsed; } ``` with $url<!-- .element: class="fragment" --> ```https://x.y; echo /etc/passwd```<!-- .element: class="fragment" --> Note: * Same system boundary problem as with SQL injection * This time directly Remote Code Execution on the shell outside PHP * An attacker can mix in instructions

## Use escapeshellarg() for arguments ```php function recruiter_job_pdf_content_extract($url) { $tika_lib_path = variable_get( 'recruiter_job_pdf_content_tika_lib_path', '/opt/tika/tika-app.jar' ); // Parse PDF using Apache Tika and output as html. $cmd = 'java -jar ' . escapeshellarg($tika_lib_path) . ' -h -eUTF-8 ' . escapeshellarg($url); $parsed = shell_exec($cmd); return parsed; } ``` Or: avoid using shell_exec() and friends!

## Injection summarized * Look in page callbacks (D7) and controllers (D8) for database queries and SQL * Look in API functions, services, plugins for shell_exec(), exec(), system() and friends * Concatenating strings (user input) is a good indicator Note: * Review database calls and shell calls super carefully and critically.

## AccessResult if() bypass<!-- .element: class="fragment" --> <pre class="stretch"><code data-trim> function taxonomy_per_user_taxonomy_term_access(EntityInterface $entity) { if (TaxonomyPerUserAccessCheck::checkCreatorAccess( '', $entity->getConfigTarget())) ) { return AccessResult::allowed(); } return AccessResult::neutral(); } abstract class TaxonomyPerUserAccessCheck { public static function checkCreatorAccess($op = NULL, $vid = NULL) { // Admin: always. if (\Drupal::currentUser()->hasPermission('administer taxonomy')) { return AccessResult::allowed(); } // Skipping some more code here... return AccessResult::neutral(); } } </code></pre> Note: * There is no comparison operator in the first if() * Access will always be allowed, which is an access bypass.

## AccessResult if() correct <pre><code data-trim data-line-numbers="2,3"> function taxonomy_per_user_taxonomy_term_access(EntityInterface $entity) { if (TaxonomyPerUserAccessCheck::checkCreatorAccess( '', $entity->getConfigTarget())->isAllowed()) ) { return AccessResult::allowed(); } return AccessResult::neutral(); } // Other code omitted here... </code></pre> * `if ($accessResult)` * will always be TRUE because it is an object and true-ish! * for access checks always use * `if ($accessResult->isAllowed())`

## AccessResult::isForbidden() trap<!-- .element: class="fragment" --> ```php public function resolve(?AccountInterface $accessUser, ?string $accessOperation, FieldContext $context) { $entity = $this->load(); /* @var $accessResult \Drupal\Core\Access\AccessResultInterface */ $accessResult = $entity->access($accessOperation, $accessUser, TRUE); $context->addCacheableDependency($accessResult); if ($accessResult->isForbidden()) { return NULL; } return $entity; } ``` Access bypass because isForbidden() is FALSE on neutral results<!-- .element: class="fragment" --> Note: * Drupal's AccessResult system has 3 states: allowed, neutral, forbidden * This is done for extensibility reasons when multiple access implementors contribute to the access result * isForbidden() only returns TRUE if access was explicitly forbidden * This is an example vulnerability from the GraphQL module that was overlooked by 3 very senior developers * Even very experienced people make mistakes; code reviews should catch them!

## AccessResult::isAllowed() is correct <pre><code data-trim data-line-numbers="8"> public function resolve(?AccountInterface $accessUser, ?string $accessOperation, FieldContext $context) { $entity = $this->load(); /* @var $accessResult \Drupal\Core\Access\AccessResultInterface */ $accessResult = $entity->access($accessOperation, $accessUser, TRUE); $context->addCacheableDependency($accessResult); if (!$accessResult->isAllowed()) { return NULL; } return $entity; } </code></pre> Familiarize yourself with allowed, neutral, forbidden access results. Note: * The basic rules is to only use isAllowed()

## [AccessResultInterface documentation](https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Access%21AccessResultInterface.php/interface/AccessResultInterface/8.8.x) > IMPORTANT NOTE\: You have to call isAllowed() when you want to know whether someone has access. Note: * This documentation is easily overlooked by developers and then they make mistakes.

## Access control summarized * Look in access hooks like hook_entity_access() * Look in access controllers (EntityAccessControlHandler) * Are the if() conditions correct? * Is any AccessResult usage correct with ->isAllowed()? * Is access cache context information set correctly? Note: * Caching information for access results can also lead to access bypass problems.

## Render array XSS Is this safe? ```php $user_input = '<script>alert("XSS");</script>'; $render_array['#markup'] = $user_input; return $render_array; ``` <ul> <li class="fragment"><strong>Drupal 8: safe!</strong> Render system runs Xss:filterAdmin() on it</li> <li class="fragment"><strong>Drupal 7: unsafe!</strong> Render system happily prints it as is</li> </ul> [OWASP A7-Cross-Site Scripting (XSS)](https://www.owasp.org/index.php/Top_10-2017_A7-Cross-Site_Scripting_(XSS)) Note: * XSS = Cross Site Scripting * An attacker tries to invoke Javascript under their control * In this case just an alert popup, but they would typically try to take over your admin account

## Twig template XSS<!-- .element: class="fragment" --> node.html.twig ```twig <article{{ attributes.addClass(classes) }}> <header> {{ title_prefix }} {% if label and not page %} <h2{{ title_attributes.addClass('node__title') }}> <a href="{{ url }}">{{ node.label|raw }}</a> </h2> {% endif %} {{ title_suffix }} </header> <div{{ content_attributes.addClass('node__content') }}> {{ content }} </div> </article> ``` Review templates if the raw filter is used correctly.<!-- .element: class="fragment" --> Note: * All variable embedding except for the one with "raw" here is fine because Twig auto-escaping is enabled

## XSS Testing Unsure if safe? Test inputs with `<script>alert("XSS");</script>`  Note: * Put this in form input fields * Put this in URL parameters that you think might be printed (reflected XSS) * Sometimes the input flow through Drupal code and modules is hard to trace * Then testing for XSS might be a good solution when unsure in code review.

## Auto-escape bypass in HTML attributes<!-- .element: class="fragment" --> node.html.twig ```twig <article> <header><h2>{{ node.label }}</h2></header> <div{{ content_attributes.addClass('node__content') }}> <img src={{ node.label }}> </div> </article> ``` attacker node title:<!-- .element: class="fragment" --> `a onerror=javascript:alert(1);`<!-- .element: class="fragment" --> ```html <img src=a onerror=javascript:alert(1);> ``` <!-- .element: class="fragment" --> Note: * The context is important to protect against XSS * The auto-escaping does not help here because no quotes are used (always quote your attributes!) * When you supply user provided data to CSS style elements then you have to be even more rigid what is allowed * The OWASP XSS cheat sheet is a good resource on how exploits can be crafted

## XSS output summarized * Drupal 8's auto-escaping is really good * Watch out what you put in HTML attributes * XSS in Drupal 7 is the most common security vulnerability! Check: * PHP templates * Theme functions * Preprocess functions * Page callbacks that generate output * check_plain() and friends should be used, see [Handle text in a secure fashion](https://www.drupal.org/docs/7/security/writing-secure-code/handle-text-in-a-secure-fashion)

## SA-CORE-2019-003 unserialize() executed on user provided data ``` GET /drupal-8.6.9/node/1?_format=hal_json HTTP/1.1 ``` ```json { "link": [ { "value": "link", "options": "<evil serialized payload>" } ], "_links": { "type": { "href": "http://192.168.1.25/drupal-8.6.9/rest/type/shortcut/default" } } } ``` Note: * Drupal core vulnerability that was fixed this year * Only exploitable if REST module and REST resources enabled * Works even on GET requests, it just needs the deserialization to happen. * The options property is a multi-purpose blob of key-value data, serialized in Druapl's database

## Evil unserialize() payload <pre> "O:24:\"GuzzleHttp\\Psr7\\FnStream\":2:" . "{s:33:\"\u0000GuzzleHttp\\Psr7\\FnStream\u0000methods\";" . "a:1:{s:5:\"close\";a:2:{i:0;" . "O:23:\"GuzzleHttp\\HandlerStack\":3:" . "{s:32:\"\u0000GuzzleHttp\\HandlerStack\u0000handler\";" . "s:12:\"echo HACKED!\";" . "s:30:\"\u0000GuzzleHttp\\HandlerStack\u0000stack\";" . "a:1:{i:0;a:1:{i:0;s:8:\"passthru\";}}" . "s:31:\"\u0000GuzzleHttp\\HandlerStack\u0000cached\";" . "b:0;}i:1;" . "s:7:\"resolve\";}}s:9:\"_fn_close\";" . "a:2:{i:0;r:4;i:1;s:7:\"resolve\";}}" </pre> Note: * Source: https://www.ambionics.io/blog/drupal8-rce * PHPGGC: https://github.com/ambionics/phpggc * The attacker abuses a PHP class from Guzzle bundled with Drupal * The Guzzle object is prepared with attacker code in it * The attacker code is executed when the deserialized object runs out of scope and the destructor is called * Similar exploits exist for Drupal 7 using other bundled classes

## unserialize() correctly * never pass user provided data to unserialize(). * Mitigation: ```php unserialize($values, ['allowed_classes' => FALSE]); ``` * Carefully examine how unserialize() is used. [OWASP A8-Insecure Deserialization](https://www.owasp.org/index.php/Top_10-2017_A8-Insecure_Deserialization) Note: * the 'allowed_classes' parameter only exists since PHP 7. * in the Drupal field case no classes are used anyway, just arrays in the serialized data

## XML External Entities attacks ```php $parsed = simplexml_load_string($user_provided); ``` Attack: ```xml <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///etc/passwd" >]> <foo>&xxe;</foo> ``` [OWASP A4-XML External Entities (XXE)](https://www.owasp.org/index.php/Top_10-2017_A4-XML_External_Entities_(XXE))

## Mitigating XEE ```php libxml_disable_entity_loader(TRUE); $parsed = simplexml_load_string($user_provided); ``` * Disable entity expansion before parsing XML.

## Full Code Review Rundown 1. Entry points (Routing Access Control, CSRF) 2. Input validation (Controllers, Injection, XEE, Deserialization) 3. Output sanitization (Templates, Theming, XSS) 4. Access Control (access logic in hooks/controllers) 5. Read through the rest Attacker mindset: how could the code be abused?

## Security as a process 1. Regular software component updates 2. Security training for developers (also stake holders) 3. Defense in depth (server, config, code, people) 4. Code review & Testing 5. Incident response plan/process 6. Penetration tests Code review is only 1 part in it!

## Resources * [OWASP Code Review Guide](https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project) * [OWASP Top Ten security risks](https://www.owasp.org/index.php/Category:OWASP_Top_Ten_2017_Project) * [Drupal 8: Writing Secure Code](https://www.drupal.org/docs/8/security/writing-secure-code-for-drupal-8) * [Drupal security coverage applications](https://www.drupal.org/project/projectapplications)

# Questions? Klaus Purer, [jobiqo.com](https://www.jobiqo.com) [drupal.org/u/klausi](https://www.drupal.org/u/klausi) <p> <a href="https://mastodon.social/@klausi"> <svg class="svg-icon" viewBox="0 0 216.4144 232.00976"> <path fill="#2b90d9" d="M211.80734 139.0875c-3.18125 16.36625-28.4925 34.2775-57.5625 37.74875-15.15875 1.80875-30.08375 3.47125-45.99875 2.74125-26.0275-1.1925-46.565-6.2125-46.565-6.2125 0 2.53375.15625 4.94625.46875 7.2025 3.38375 25.68625 25.47 27.225 46.39125 27.9425 21.11625.7225 39.91875-5.20625 39.91875-5.20625l.8675 19.09s-14.77 7.93125-41.08125 9.39c-14.50875.7975-32.52375-.365-53.50625-5.91875C9.23234 213.82 1.40609 165.31125.20859 116.09125c-.365-14.61375-.14-28.39375-.14-39.91875 0-50.33 32.97625-65.0825 32.97625-65.0825C49.67234 3.45375 78.20359.2425 107.86484 0h.72875c29.66125.2425 58.21125 3.45375 74.8375 11.09 0 0 32.975 14.7525 32.975 65.0825 0 0 .41375 37.13375-4.59875 62.915"/> <path fill="#fff" d="M177.50984 80.077v60.94125h-24.14375v-59.15c0-12.46875-5.24625-18.7975-15.74-18.7975-11.6025 0-17.4175 7.5075-17.4175 22.3525v32.37625H96.20734V85.42325c0-14.845-5.81625-22.3525-17.41875-22.3525-10.49375 0-15.74 6.32875-15.74 18.7975v59.15H38.90484V80.077c0-12.455 3.17125-22.3525 9.54125-29.675 6.56875-7.3225 15.17125-11.07625 25.85-11.07625 12.355 0 21.71125 4.74875 27.8975 14.2475l6.01375 10.08125 6.015-10.08125c6.185-9.49875 15.54125-14.2475 27.8975-14.2475 10.6775 0 19.28 3.75375 25.85 11.07625 6.36875 7.3225 9.54 17.22 9.54 29.675"/> </svg> klausi@mastodon.social </a> </p> <a href="https://twitter.com/_klausi_"> <svg class="svg-icon" viewBox="0 0 400 400"><defs><style>.cls-1{fill:none;}.cls-2{fill:#1da1f2;}</style></defs><title>Twitter_Logo_Blue</title><rect class="cls-1" width="400" height="400"/><path class="cls-2" d="M153.62,301.59c94.34,0,145.94-78.16,145.94-145.94,0-2.22,0-4.43-.15-6.63A104.36,104.36,0,0,0,325,122.47a102.38,102.38,0,0,1-29.46,8.07,51.47,51.47,0,0,0,22.55-28.37,102.79,102.79,0,0,1-32.57,12.45,51.34,51.34,0,0,0-87.41,46.78A145.62,145.62,0,0,1,92.4,107.81a51.33,51.33,0,0,0,15.88,68.47A50.91,50.91,0,0,1,85,169.86c0,.21,0,.43,0,.65a51.31,51.31,0,0,0,41.15,50.28,51.21,51.21,0,0,1-23.16.88,51.35,51.35,0,0,0,47.92,35.62,102.92,102.92,0,0,1-63.7,22A104.41,104.41,0,0,1,75,278.55a145.21,145.21,0,0,0,78.62,23"/></svg> twitter.com/_klausi_ </a>

# Bonus slides

## PHP language fails Access Bypass because of a typo ```php function checkSharedKey($shared_key) { if (strlen($shared_key) != 32) { return false; } if (trim($shared_key) == "") { return flase; } … } ``` <pre> Warning: Use of undefined constant flase - assumed 'flase' (this will throw an Error in a future version of PHP) </pre> Note: * Example source: https://medium.com/@DanielC7/remote-code-execution-gaining-domain-admin-privileges-due-to-a-typo-dbf8773df767 * PHP issues a warning, but the function will return a truthy value * If you don't compare that with "===" then you get an access bypass

## PHP type hinting as security protection Use declare() and a return type hint: ```php declare(strict_types=1); function checkSharedKey($shared_key): bool { if (strlen($shared_key) != 32) { return false; } if (trim($shared_key) == "") { return flase; } … } ``` <pre> Fatal error: Uncaught TypeError: Return value of checkSharedKey() must be of the type bool, string returned </pre> Note: * Instead of a warning we get a fatal error now with this * code execution will stop and the typo cannot be exploited.