Martin Kruliš by Martin Kruliš (v1.0)1

by Martin Kruliš (v1.0)2

 Single Point of Entry ◦ One bootstrap script (e.g., index.php )  Per application or service, not per page  Including Scripts ◦ Declarations only, no effective code ◦ Not directly accessible by web server  In separate directory, blocked by.htaccess ◦ Included only once  include_once(), require_once(), autoloading ◦ Exceptions  Only very few – e.g., HTML templates by Martin Kruliš (v1.0)3

 HTTP ◦ Built on TCP, not encrypted  HTTPS ◦ Encrypted data transfers ◦ TSL layer between TCP and HTTP ◦ Matter of web-server configuration  And SSL certificate selection ◦ Ensuring secure connection  Verify whether $_SERVER['HTTPS'] == 'on';  Redirect in case of failure (to URL) ◦ Encryption is not everything … by Martin Kruliš (v1.0)4

 HTTPS ◦ Not all powerful, handle the contents carefully ◦ Often rely on correctness of 3 rd party libraries  Like OpenSSL ◦ Based on the hope that factorization-based cryptography is secure ◦ History taught us to be caution…  CCS Injection Vulnerability  Heartbleed bug  Poodle bug  Predictable keys vulnerability (Debian)  … by Martin Kruliš (v1.0)5

 Script Parameters ◦ GET (from URL) and POST  Usage of $_REQUEST array is not recommended ◦ Ensuring integrity  All incoming parameters need to be validated  By regular expressions, by conversion to numeric types, …  User can easily modify URL or hidden form fields ◦ Prevent sensitive data caching/resending  POSTed data are cached by browser  Can be correctly solved by using redirect after each POST query by Martin Kruliš (v1.0)6

 Securing the Database System ◦ DBMS must be in the “trusted base”  Particular problem for cloud applications ◦ Separate account for PHP script  With minimal rights ◦ Frequent backups  Sensitive Data ◦ Encrypted or hashed by a strong hashing function ,hashfnc(, ) ◦ PHP has built-in functions for password hashing  crypt(), password_hash(), password_verify() by Martin Kruliš (v1.0)7 PHP 5.5

 Database Inputs ◦ Possibility of SQL injection attack ◦ Sanitize ALL user inputs  Preferably use prepared queries and variable binding by Martin Kruliš (v1.0)8 (Exploits of a Mom)

 HTML (JavaScript) Injection ◦ User provided inputs are inserted into HTML ◦ Code can be inserted in tag  JavaScript can read cookies and send them ◦ htmlspecialchars() – sanitizes data for HTML  PHP Injection ◦ Data are used in eval(), include(), require(), …  Shell Injection ◦ Data are used in system(), exec(), shell_exec(), … by Martin Kruliš (v1.0)9

 Authentication Process ◦ Verifies identity of a user (e.g., by login-passwd) ◦ The greatest challenge is to keep the information  HTTP is stateless, IP verification is not enough  Authentication must be repeated with each request  Without user’s interaction  Authentication Solution ◦ Authentication tokens must be saved on both sides  Slightly complicated on the client side ◦ Tokens must not be stolen  Big issue in web browser security by Martin Kruliš (v1.0)10

 Problem of Cross Site Scripting (XSS) ◦ Malicious client-side script injected in the page ◦ Copies security tokens and sends them to attacker ◦ Attacker uses the tokens to assume the identity  Protection Guidelines ◦ Secure connection ◦ Data are sanitized before inserted into HTML ◦ Protecting cookies from XSS (HttpOnly flag) ◦ Additional Techniques  Security tokens have expiration time  IP (browser) verification, multiple security tokens, … by Martin Kruliš (v1.0)11

 Authentication Embedded in HTTP ◦ If the auth. information are provided, they are in  $_SERVER['PHP_AUTH_USER']  $_SERVER['PHP_AUTH_PW'] ◦ The script can request authentication data header('WWW-Authenticate: Basic realm="Auth test"'); header('HTTP/ Unauthorized'); exit; ◦ Potential problems  Password is sent with every request  Logout operation is not very well defined by Martin Kruliš (v1.0)12

 Authorization ◦ Process of verification access rights of the user  Security Model ◦ Defines protected objects, authorities, operations ◦ Simple (state-less) models  Function (object, authority, operation) -> yes/no ◦ More complex models exist  Implementation ◦ Single module (class, function, …) ◦ Two phase verification (when the controls are rendered and when the action is performed) by Martin Kruliš (v1.0)13

 Directory (Capability List) ◦ Authorities have lists of accessible objects  Access List ◦ Protected objects have lists of users (+permissions)  Access Control Matrix ◦ Matrix Authorities-Objects, each item describes access restrictions  Bell-La Padula ◦ Each authority has level of access, each object has minimal required level of access by Martin Kruliš (v1.0)14

 Minimal Rights Principle ◦ Permissions are explicit, denials are implicit  Aggregation of Permissions ◦ User groups (e.g., as in unix systems)  Group permissions are inherited by members ◦ Security Roles  Security templates adopted by users ◦ Capabilities  (Temporary) permissions – like a cinema ticket  Usually used in combination with more complex verifications (that are computationally demanding) by Martin Kruliš (v1.0)15

 Backups and Logs ◦ Backups are useful not only for security breaches ◦ Responsibility tracking is also important  Software Updates ◦ Some exploits uses bugs in PHP, web server, or the database management system  Be Tidy ◦ Remove old information from URLs, cookies, … ◦ Destroy sessions when no longer used ◦ Restrict access to unnecessary files, data, … by Martin Kruliš (v1.0)16

by Martin Kruliš (v1.0)17