Web Security

Recommendations Against CSRF (aka XSS – cross site scripting)

(cross site request forgery) – an attack whereby a user from an outside source sends a request to a web application that a user has already authenticated itself with, from a different website.

Ways to prevent XSS

     1. using $_POST not $_REQUEST on inputted fields– this will prevent malicious users from scripting elements that rely on a basic $_GET
    eg:

2. hashed token in session checked on each page
  eg:
  (outgoing PHP Response) – send a unique ID ‘token’ out to the user’s ‘to-be-submitted’ form
 

(Incoming PHP Request) – check the token after it returns – make sure it’s still who we expect it to be

3. Putting a timeout on the hashed token (I didn’t say token hash).

4. Enforcing session timeout and limit it to a minimum.
  How this can affect security:
a) The user leaves workstation and browser cache. Someone else can access. medium risk.

b) The more serious in your case, session hijacking. To hijack a session all one needs is the sessionid. Normally you'd check if the session belongs to the user, but if session identifies the user you can't. Then all that is required to hijack a session, is to guess (easier if never expires) or catch with a network sniffer.

5. Don't waste time with checking $_SERVER['HTTP_REFERER'] since that only stops attacks from a browser
  **everyone’s initial response to “how should we secure the system?”
 
  6. Put into htaccess file directives that disallow SQL injection keywords in the query string (delete/drop/insert etc)
 
  7. Fail open error handling (remove all 'ugly error' messages).  
  Users should NEVER know what error happened, only that an error DID happen. This is where logging comes in for our debug audit on a proper log file. Showing the user that a file at /home/fvreb/public_html/includes/lang/en/eng-ca.php could not be found is not a wise solution for showing hackers the directory structure.
 
  8. Validation– make sure banned terms and invalid characters are not passed into the system.
 
  9. Use striptags() on user input before saving to remove NULL bytes, HTML and PHP tags stripped from a given string input.
 
  10. Using a ‘captcha’ image on submitted forms. Ensures it’s not a script executing.
 
  11. HTML encode user-supplied data that is embedded into a returned page (ie a confirmation before submition). Again this would be preventing things like this from being printed to the page:

12. Post vs Get in Ajax calls.
GET should be used for what it is intended for: Getting data from the server (not sending), without changing state on the server. It should not be used to update resources on the server. POST or PUT are designed for that. Using HTTP the way it was intended to be used both helps avoid some (but far from all) XSS attacks, it also makes browsers behave a lot nicer when communicating with your site. The browser expects that GET requests can be safely repeated, without requiring confirmation from the user. That's what it does if you refresh the page, for example, or use the back/forward buttons. POST is expected to change state on the server, so the browser typically asks for confirmation before repeating a POST request.

AJAX Issues

  Many issues can be found in AJAX calls since developers often pass queries as GET methods out of habit. Changing the queries to POST and then checking to ensure that they are only posted parameters on the receiving end also helps mitigate SQL and XSS injections.
  Adding the random tokens on all queries will help against XSS – JQUERY has a built in method. Standard AJAX outside of frameworks will need to be manually adjusted.
 
  JQuery Tricks
  To use this token with jQuery, you need to make it available to javascript. You typically do this by adding it as a javascript variable.
  var csrf_token = '';//random generated query drawn on serverside

Next, the trick is to bind to the global ajaxSend event, and add the token to any POST request

Ways to Track and Trace XSS Attempts

  1. Maintain audit logs and create a banned IP list
  2. Key event should be logged, which typically include:

 
•    all events relating to the authentication functionality, such as successful and failed login, and change of password
 
•    key transactions, such as credit card payments and funds transfers
 
•    access attempts that are blocked by the access control mechanisms
 
•    any requests containing known attack strings that indicate overtly malicious intentions
 
•    logging used by banks will track every single client request with complete forensic record that can be used to investigate further incidents and allow for fixes based on that information
 
•    log time of each event, IP address, session token, user's account (if authenticated)
   
    **these logs need to be strongly protected against unauthorized re/write access. An effective approach is to store audit logs on an autonomous system that accepts only update messages from the main application. In some situations, logs may be flushed to a write once media (CD) to ensure integrity in the event of a successful attack

• poorly protected audit logs can provide a gold mine of information to an attacker, disclosing a host of sensitive information such as session tokens and request parameters that may enable them to immediatley comprimise the entire application

3. installation of alerting mechanisms that monitor traffic and anomalies such as:

     
•        large numbers of requests being received from a single IP address or user, indicating a scripted attack
     
•        business anomalies, such as unusual number of funds transfers to/from a single account
     
• requests containing known attack strings
     
•        requests where data that is hidden from ordinary user has been modified (eg: token changed)
     
•        off the shelf intrusion detection software on server
          It’s important to note that reacting to apparent attacks is not a substitute for fixing vulnerabilities but even the most efforts to purge an application of security flaws may leave some exploitable defects remaining. Placing further obstacles in the way of an attacker is an effective defense-in-depth measure that reduces the likelihood that residual vulnerabilities will be found and exploited.

Validation and Sanitization

Validation– preventing the process from continuing due to the presence of disallowed characters
          Sanitization– removal of disallowed characters without disrupting the flow of the process
    Things to check for:

         
•            control characters
         
•            non alphanumeric (symbols, etc)
         
•            excessive lengths
         
•            spam
         
•            binary data
         
•            alternate encoded data (ascii, unicode, utf-8, hex, octal)
         
•            sql injection
         
•            code injection