$30 off During Our Annual Pro Sale. View Details »

Common Web Security Issues and Tips on How to Overcome Them

Common Web Security Issues and Tips on How to Overcome Them

When we are talking about web, security is not for granted. Every day we read about (or worse: experience) systems getting compromised or data being lost as a result of attacks or negligence.With theses slides I try to alert about some of the most common or dangerous problems I could think of.

Henrique Vicente

July 31, 2012
Tweet

More Decks by Henrique Vicente

Other Decks in Programming

Transcript

  1. Common Web Security Issues and
    Tips on How to Overcome Them
    When we are talking about web, security is not for granted. Every day we read about (or worse: experience)
    systems getting compromised or data being lost as a result of attacks or negligence. With theses slides I try to
    alert about some of the most common or dangerous problems I could think of.
    Henrique Vicente de Oliveira Pinto
    Tuesday, July 31, 2012
    Recife, Brazil
    https://github.com/henvic/
    http://twitter.com/henriquev
    [email protected]
    1
    Tuesday, July 31, 12

    View Slide

  2. First web server
    2
    Tuesday, July 31, 12

    View Slide

  3. HTTP
    • stateless protocol
    • each request is unique
    - even for persistence connections
    - even for different hosts on the same IP
    3
    Tuesday, July 31, 12

    View Slide

  4. Cookies
    4
    Tuesday, July 31, 12

    View Slide

  5. HTTP Cookie
    • small piece of persistent data shared between client and server
    • reliable mechanism to track the user (i.e., authentication)
    • but...
    5
    Tuesday, July 31, 12

    View Slide

  6. 6
    Tuesday, July 31, 12

    View Slide

  7. Security concerns
    • The HTTP Cookie architecture is “not designed for security”
    • You have to take proper care about securing your system
    7
    Tuesday, July 31, 12

    View Slide

  8. Bad Cookie Example
    • sensitive consumer data (credit card) on store.product.com
    • blog powered on product.com, by Wordpress
    - Wordpress is not designed to be PCI DSS compliant
    - risk: example.com can read/write cookies for store.example.com
    8
    Tuesday, July 31, 12

    View Slide

  9. Content Delivery Network
    • A content delivery network (CDN) is a collection of web servers
    distributed across multiple locations to deliver content more
    efficiently to users (low latency, high data transfer speeds, reliability).
    9
    Tuesday, July 31, 12

    View Slide

  10. Some popular CDNs
    • a*.twimg.com for twitter.com
    • th*.deviantart.net for deviantart.com
    • farm*.staticflickr.com for flickr.com
    10
    Tuesday, July 31, 12

    View Slide

  11. Principle of least privilege
    • *.fbcdn.net for twitter.com
    Notice the different domain. Most browsers limit the amount of
    connections per domain. The trade-off is just a additional DNS-lookup.
    • You can set cookies for your *.domain (subdomains) and still your
    cookies doesn’t get sent to your CDN
    11
    Tuesday, July 31, 12

    View Slide

  12. Herd of elePHPants
    12
    Tuesday, July 31, 12

    View Slide

  13. Sessions
    • Way to store certain client data on the server-side across multiple
    requests
    • Uniquely identified by some form or another:
    - cookies
    - URL params (come again?)
    13
    Tuesday, July 31, 12

    View Slide

  14. http://pa.ge/?SID=aa7d8abb7
    • URI params are evil:
    - Prone to unintentional disclosure, injection, etc.
    - If you see anything like SID= or session_id= on the URI params
    chances are the page you’re accessing is compromised
    • POST-based sessions is not a solution & breaks the REST paradigm.
    • You must only accept cookies-based sessions.
    14
    Tuesday, July 31, 12

    View Slide

  15. Security tips for PHP
    • Make sure session.use_trans_sid is disabled
    • Make sure session.use_cookies is enabled (if you want it)
    • Use the least release of PHP (that means 5.4 as of July 2012)
    - if you use must use earlier versions, make sure register_globals is
    turned off and (of course) safe_mode is on.
    15
    Tuesday, July 31, 12

    View Slide

  16. eval() is evil (in any language)
    • If you are using eval() there is almost certainly a better approach
    • If eval() is the response, you’re almost certainly making the wrong
    question
    • eval() is slow
    • eval() is dangerous
    - real-life example I’ve seen: routing system
    - “hey, why can’t I have a page called /exit?”: (exit = reserved word)
    16
    Tuesday, July 31, 12

    View Slide

  17. Securing your sessions
    • Session fixation issue:
    1. user sets a cookie with the fake session id for someone else
    2. the victim access the website with that given cookie, which is
    accepted, and his account is taken over remotely.
    • Solution:
    Only accept session IDs created by yourself (i.e., initialize it with a
    custom data: if someone doesn’t have it, destroy the cookie and create
    a new session for the user)
    17
    Tuesday, July 31, 12

    View Slide

  18. Prevent session fixation
    • Don’t reuse sessions. After any significant change (such as login or
    logout), generate a new session id:
    i.e., session_regenerate_id();
    Otherwise, a user might use a computer and note down the current
    session, then go away and keep testing until someone else has logged
    in and hijack the account.
    18
    Tuesday, July 31, 12

    View Slide

  19. More on session hijacking
    • Set-Cookie with the HttpOnly flag might help you with avoiding script
    kiddies trying XSS attacks to hijack your cookies due to a bad
    implemented HTML sanitizer or something.
    It tells (some modern browsers which implements it) that the cookie
    should be accessed only by the server, not by the client.
    Might help, but it gives you a false sense of security.
    19
    Tuesday, July 31, 12

    View Slide

  20. Supercookie
    20
    Tuesday, July 31, 12

    View Slide

  21. Supercookie
    • If a www.example.com or store.product.com can read/write a cookie
    for example.com, why can’t it write for .com? Or... Can it?
    21
    Tuesday, July 31, 12

    View Slide

  22. Supercookie
    • Not tasty
    • Public Suffix List saves the day by letting browsers know if someone is
    trying to set a super-cookie or not.
    - A "public suffix" is one under which Internet users can directly
    register names: i.e., .com, .co.uk, and .com.br
    http://publicsuffix.org/
    22
    Tuesday, July 31, 12

    View Slide

  23. Zombie cookie
    23
    Tuesday, July 31, 12

    View Slide

  24. Zombie cookie
    • A cookie that comes back
    1. its data is also stored with localStorage or another way
    2. when erased, it is recreated
    • Please, don’t use it.
    24
    Tuesday, July 31, 12

    View Slide

  25. How the DNS works
    • Solving a name to a IP(s) may involve:
    - desired service (HTTP, mail server, samba, etc)
    - geolocation
    - available resources
    - load balancing
    - etc
    25
    Tuesday, July 31, 12

    View Slide

  26. How the DNS works
    • Shared nothing architecture
    - it is not centralized. Instead, several it’s a network of several servers
    world-wide working together, alone. There is not a single point of
    failure so it is fast and reliable.
    26
    Tuesday, July 31, 12

    View Slide

  27. DNS cache poisoning
    • A “rogue” DNS server may contain wrong information
    - this may help either by configuration problem or intentionally
    • So a compromised DNS server may, for example, make your
    connection to a website fail or... Someone might route your traffic
    trough a proxy and listen to your traffic, hijacking your session ids, etc.
    27
    Tuesday, July 31, 12

    View Slide

  28. Sniffing: eavesdropping
    • Unencrypted data (such as regular HTTP) can be easily listened to.
    • In physical connected network: might be expensive, work intensive,
    might leave traces and be more complicated.
    • But what about the wi-fi hotspot on your preferred café?
    28
    Tuesday, July 31, 12

    View Slide

  29. Sniffing: eavesdropping
    • Wi-fi is not secure by design. Encrypted network? Good. But if your
    passphrase is know by the attacker, you’re compromised.
    • A weak passphrase may also be easily discovered by eavesdropping.
    29
    Tuesday, July 31, 12

    View Slide

  30. How to fix it?
    • Encrypted traffic is the way.
    • You can tunnel YOUR data to a secure tunnel at home.
    - Make sure your tunnel is secure
    - is your home a safe heaven?
    - what about the data that goes beyond it?
    - it fixes the problem of wi-fi eavesdropping, but is not good
    enough for everything.
    • What about your users and sensitive info?
    30
    Tuesday, July 31, 12

    View Slide

  31. HTTPS = HTTP + SSL/TLS
    • A combination of protocols
    • Reduces the points of failure
    • Renders the man-in-the-middle attacks inefficient
    • Renders DNS poisoning attacks (alone) inefficient
    • TLS = evolution of SSL
    • Limitation: no more than one validly certified secure web site on a IP due to the HTTPS protocol design.
    31
    Tuesday, July 31, 12

    View Slide

  32. HTTPS = HTTP + SSL/TLS
    • Keep in mind: you are using a secure protocol for a reason
    • This means: your JavaScript, CSS, and images should also use HTTPS
    • At least your JS (given that’s a programming client-side script) and
    private images or files associated with your system (not part of the
    layout).
    32
    Tuesday, July 31, 12

    View Slide

  33. Secure cookie
    • Set-Cookie with the Secure flag (over the HTTPS, of course)
    • So it is not sent over a insecure (regular HTTP) connection.
    • Otherwise if your user connect over regular HTTP the cookie data is
    compromised.
    33
    Tuesday, July 31, 12

    View Slide

  34. How the HTTPS protocol works
    • We have Certificate Authorities (CAs):
    - VeriSign
    - Thawte
    - RSA Security
    - Cisco
    - AOL Time Warner
    - (many others...)
    34
    Tuesday, July 31, 12

    View Slide

  35. About certificates
    • A Certificate Authority is a entity that issues digital certificates
    • Most browsers have the root certificate of a dozen of CAs
    • A certificate is a document which can be used to verify that a public
    key belongs to an individual
    35
    Tuesday, July 31, 12

    View Slide

  36. About certificates
    • Not every certificate is the same. There are different levels of
    certificates.
    • A certificate is (hopefully) signed by a recognized CA root certificate
    and checked against its invalidation list
    • A certificate can be self-signed (stupid, not recommended, and useful)
    • They have expiration dates
    36
    Tuesday, July 31, 12

    View Slide

  37. Extended Validation (EV)
    Certificate
    • Extensive verification of
    identity before emitting
    the certificate to the
    requester
    • No more secure than a
    non-EV certificate
    • Might make part of your
    address bar green, etc.
    37
    Tuesday, July 31, 12

    View Slide

  38. Certificates
    • Software vendors (like Apple or Ubuntu) trusts the most appreciated
    CAs and embed their public keys in their systems. If you are a
    incompetent CA you’re out of the market (hopefully).
    • You trust your browser & operational system
    • You check the identity to whom the certificate belongs to (don’t you?)
    38
    Tuesday, July 31, 12

    View Slide

  39. Certificates for intranet
    • If you have a certificate for http://secret-docs.intranet/ you’re doing it
    wrong:
    - There might be others secret-docs.intranet on others intranets,
    including the one from the bad guy wanting to steal your data
    • Sadly, some CAs does emit certificates for them
    • You’d have to read the certificate document each time before allowing
    your browser to send sensitive data (session IDs, anyone?) to the
    requesting server: not gonna happen.
    39
    Tuesday, July 31, 12

    View Slide

  40. Fixing your intranet server security
    • http://secret-docs.intranet.your-domain.example.com/
    • You can still restrict it to be accessible only inside the intranet, but
    now it is now safer (just be aware of wildcard SSL certificates which
    you don’t want to trust).
    40
    Tuesday, July 31, 12

    View Slide

  41. Deploying your website or app
    • Are you still using FTP?
    - Don’t.
    41
    Tuesday, July 31, 12

    View Slide

  42. FTP is...
    • really slow
    • insecure
    • complicated, prone to errors
    42
    Tuesday, July 31, 12

    View Slide

  43. Great deployment tools
    • WebDAV over HTTPS (great native support in modern machines)
    • SFTP (based on SSH; and is NOT ‘secure FTP’)
    • git push
    • torrent (if you are Facebook, Twitter, and the like - and know what
    you’re doing this is almost certainly the best option)
    43
    Tuesday, July 31, 12

    View Slide

  44. Sending email
    • Does your mail sender have proper permission? Like...
    MX records for the domain you are sending?
    SPF1, SPF2 maybe?
    • If you don’t, it may end up as Spam.
    44
    Tuesday, July 31, 12

    View Slide

  45. Sending email
    • Don’t keep the user waiting:
    - Queue the message with a local relay
    • Using PHP? Do yourself a favor and avoid mail();
    - for security, simplicity, and performance
    - use PEAR Mail_Mime or Zend_mail
    45
    Tuesday, July 31, 12

    View Slide

  46. Text Encoding
    • UTF-8 is here to stay
    • you must adopt UTF-8 or you lose consumers
    • however...
    46
    Tuesday, July 31, 12

    View Slide

  47. Intelligent UTF-8
    • Adopt with care:
    • you don’t want two usernames like: “frédéric” and “frederic”
    - (just the second if you don’t mind, please).
    • But you want different passwords to be different:
    “n” is not “ñ”
    - (ok, don’t use single-letters for passwords)
    47
    Tuesday, July 31, 12

    View Slide

  48. txt.evihcra.exe = exe.archive.txt?
    • UTF-8 has tricky control characters like one which shows the text
    inverted
    • for example: it might make someone execute a file thinking it is just a
    text file, when it actually is a binary one
    48
    Tuesday, July 31, 12

    View Slide

  49. UTF-8 is tricky
    • bad encoded UTF-8 with invalid byte sequences is also a headache
    • Byte order mark (“”) on top of your PHP files makes you insane:
    - “how come the headers are already sent?”
    or
    - “why is this JSON invalid in this browser and not in that one?”
    anyone...?
    49
    Tuesday, July 31, 12

    View Slide

  50. UTF-8 is tricky
    • There is more than half a dozen reasons why you use a IDE, or a great
    text editor.
    • Don’t use Wordpad or Notepad to make a quick change on your
    code, please. BOM (0xEF, 0xBB, 0xBF) will happen.
    • And check what you commit (you do versioning right, don’t you?) and
    if you see something weird or unexpected... Do something about it.
    50
    Tuesday, July 31, 12

    View Slide

  51. User input data
    • On PHP:
    - Zend_Form, Zend_Filter, and Zend_Validate forms a great toolkit (a
    loosely coupled one)
    • Always filter and validate each data entry
    51
    Tuesday, July 31, 12

    View Slide

  52. What a filter should do
    • Filtering in action:
    - telephone:
    input: "700-7202222", output: "+1-700-720-2222"
    - name:
    input: " Henrique Pinto ", output: "Henrique Pinto"
    - price:
    input: "0.51 ", output: "$0.51 USD"
    • Filter might strip whitespaces, normalize input, etc.
    52
    Tuesday, July 31, 12

    View Slide

  53. What a validator should do
    • Checks if the given data (post-filtered) is valid
    • If not valid:
    - give feedback telling why it didn’t pass
    • Examples:
    - telephone: "+1" (error: incomplete phone number)
    - price: "" (error: price is required, price can not be empty)
    - price: "0" (not a error: product is free)
    53
    Tuesday, July 31, 12

    View Slide

  54. Don’t mix unfiltered with filtered
    data
    • $result = array(
    "filtered" => array(
    "name" => "Nick", "seat" => "4H"
    ),
    "unfiltered" => array(
    "name" => "Nick\n", "seat" => "4 h"
    ),
    "validate" => array(
    "name" => true, "seat" => array("errors" => array("invalid-seat"))
    )
    );
    • Keep them explicitly apart.
    54
    Tuesday, July 31, 12

    View Slide

  55. Filtered data != escaped data
    • NOT
    55
    Tuesday, July 31, 12

    View Slide

  56. Sanitize on input, escape on output
    • Take a whitelist approach (rather than a blacklist one):
    - parsing HTML is more complicated than what seems.
    - HtmlPurifier is a great (the best?) HTML parser library for PHP
    Just make sure to cache it. Sadly it is a little bit complicated and not good with internationalized URIs.
    - don’t build your own parser (unless the parser itself is your goal)
    • i.e., phone number
    - first character may be “+”, others are digits (and no more than ~20)
    • escape at each step: SQL, HTML, JSON, BASH, Regex, XML, etc.
    - escaping isn’t magic, each step requires different types of escaping
    56
    Tuesday, July 31, 12

    View Slide

  57. Sanitize on input, escape on output
    • know your tools
    - MySQL is way more permissive (in the bad sense) than Postgresql
    - try to add “test” to a char(2) field on a MySQL DB:
    - it will save “te”, Postgresql would fail emitting a notice that the
    data is larger than the space of the field.
    • Don’t take external APIs data for granted, take the same care with
    them as you would with user input data
    57
    Tuesday, July 31, 12

    View Slide

  58. User input data: Null-Byte Attack
    • PHP uses C functions for FS calls for which null-byte = end of string
    • http://example.com/place?inc=../../../etc/passwd%00ignored
    if we try to read a file with the inc param, we read:
    "../../../etc/passwd" instead of "../../../etc/passwd/%00ignored".
    Fix: remove the null-byte: str_replace(chr(0), "", $param);
    Checking for "../" might seem “good enough”, but defense in depth >> “good enough”.
    • Note: in my tests if the %00 was in path part Apache and nginx
    returned a Bad Request page, but if you have this issue, fix it anyways.
    More on https://github.com/henvic/MediaLab/issues/9
    58
    Tuesday, July 31, 12

    View Slide

  59. Common problem with PHP +
    MySQL
    • Problematic: "SELECT * WHERE user = " . addslashes($username);
    addslashes() is useless. Use the proper functions available for the
    database adaptor you are currently using.
    • Fixing with PDO:
    $sth = $dbh->prepare("SELECT * WHERE user = :username");
    $sth->bindParam(":username", $username, PDO::PARAM_STR, 10);
    * last argument is length
    59
    Tuesday, July 31, 12

    View Slide

  60. memcached caveats
    • It doesn’t carry the concept of different databases.
    A prefix in the key part will suffice to fix this limitation:
    - e.g., keys: session_S929JDLRJ223, cache_page_index, profile_henvic
    • By default, it allows connection from any client with no authentication.
    SASL might be used. Strict firewall rules are advised.
    Sadly many memcached installs on production environments are unprotected.
    • Same should apply for the fork Twemcache
    60
    Tuesday, July 31, 12

    View Slide

  61. A safe example
    • $sth = $dbh->prepare("SELECT * from fruits WHERE calories
    < :calories AND color = :color");
    • $sth->bindValue(":calories", $calories, PDO::PARAM_INT);
    • $sth->bindParam(":color", $color, PDO::PARAM_STR, 10);
    • $sth->execute();
    61
    Tuesday, July 31, 12

    View Slide

  62. Storing passwords: don’t
    62
    Tuesday, July 31, 12

    View Slide

  63. Storing passwords: don’t
    • Breaking passwords is each day more easily done
    • Rainbow Tables out there helps cracking passwords easily
    • Adding a salt helps, but that alone isn’t enough & time-proven
    • If you are just hashing with MD5, SHA1, SHA256, SHA512, etc you’re
    doing it wrong.
    • Even if your system is just a game, remember users are lazy and reuse
    their passwords from games to banking accounts, so be responsible
    63
    Tuesday, July 31, 12

    View Slide

  64. Solution
    • Generic algorithm
    - that can not be optimized with dedicated hardware
    • Adaptive
    - as hardware increases you can make it harder / slower with more
    iterations than before
    64
    Tuesday, July 31, 12

    View Slide

  65. A Future-Adaptable Password
    Scheme
    65
    Tuesday, July 31, 12

    View Slide

  66. bcrypt
    The original implementation was for OpenBSD
    66
    Tuesday, July 31, 12

    View Slide

  67. bcrypt
    • You can increase the iterations needed to calculate if a password
    matches with a given hash
    • Rainbow tables are impossible
    • Implementation for PHP: http://www.openwall.com/phpass/
    67
    Tuesday, July 31, 12

    View Slide

  68. Password
    • Alternatives to bcrypt:
    - scrypt: slightly more secure, seems to be less supported
    - PBKDF2: less secure
    • Read about the subject
    - https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
    68
    Tuesday, July 31, 12

    View Slide

  69. Brute-force attacks
    • Doors to Denial-of-service
    - compute-intensive password hashing methods
    - compute-intensive actions triggered by the final users
    - ...
    • Doors to security compromise
    - dictionary attacks to your login form
    - ...
    • Limit requests at the front-end servers or the application level
    - i.e., HttpLimitReqModule on nginx, captchas (tip: reCAPTCHA)
    69
    Tuesday, July 31, 12

    View Slide

  70. Two-factor authentication
    • Extra protection against unauthorized access
    • Various technologies:
    - SMS one-time password
    - Time-based One-time Password Algorithm
    - Hardware-based (i.e., RSA tokens)
    - Software-based (i.e., Google Authenticator)
    • Various implementations, services, and APIs
    for using with SSH, HTTP(S), etc are available.
    70
    Tuesday, July 31, 12

    View Slide

  71. Captcha
    • Completely Automated Public Turing test to tell Computers and
    Humans Apart
    • It’s intrusive (you don’t want to use everywhere, every single time):
    - i.e., use [after 3 or 4] failed authentication attempts
    (even have the great side-effect of throttling down the attack)
    • A bad implementation might make experience for people with
    disabilities or accessing via mobile a very bad thing
    71
    Tuesday, July 31, 12

    View Slide

  72. • Originally developed at Carnegie Mellon University
    • Acquired by Google
    • Web service for free
    • Support for blind (with audio), etc
    • Constantly up-to-date
    • Use it instead of implementing your own
    72
    Tuesday, July 31, 12

    View Slide

  73. Panopticlick
    • How Unique - and Trackable - Is Your Browser?
    • https://panopticlick.eff.org
    • As it turns out our browsers gives up too much information
    - even in private mode
    73
    Tuesday, July 31, 12

    View Slide

  74. HTTP is all about being RESTful
    • REpresentational State Transfer (REST) >> SOAP > WSDL
    • In theory: HEAD, GET, POST, PUT, DELETE, TRACE, OPTIONS,
    CONNECT, PATCH.
    • In practice: GET and POST are the most popular.
    • Keep in mind: the standard is all about SHOULD, not MUST.
    Refer to: “Key words for use in RFCs to Indicate Requirement Levels” http://tools.ietf.org/html/rfc2119
    74
    Tuesday, July 31, 12

    View Slide

  75. Powerful GET?
    • GET SHOULD NOT be used for transformation / destructive actions.
    • Why?
    - It should be used to... get content.
    - It can be easily forged.
    - It can be unintentionally / automatically retrieved.
    • Must use? Add token (hash) + check origin (referrer) + hide link from
    user + rel="nofollow" + find another way to do so + etc
    • Really? Isn’t the case for a hidden field in a form or something better?
    75
    Tuesday, July 31, 12

    View Slide

  76. A word on XML
    • Prefer JSON over XML
    - Why?
    - Because is simpler
    - Less complicated
    - Easer to parse
    Only major drawback:
    - More hard on the human eyes (subjective)
    76
    Tuesday, July 31, 12

    View Slide

  77. Another word on XML
    • Forget ]]>
    - Why complicate things? Just escape your message the right way.
    • Use libraries instead of trying to write XML by hand:
    - PHP: SimpleXML
    - Not as powerful as DOM, but maybe good enough
    - Abstraction, easer code, less headaches
    77
    Tuesday, July 31, 12

    View Slide

  78. Apache and .htaccess
    • .htaccess is evil
    - slow
    - reduced I/O + bottleneck on the disk
    - even insecure
    - invite for adopting bad practices
    • A problem: server-side executables / code on the public area
    - public_html/
    /index.php
    /.htaccess
    /lib/.htaccess
    ...
    78
    Tuesday, July 31, 12

    View Slide

  79. PHP(?), Apache and .htaccess
    • You don’t want your application and credentials accessible for the
    external world: what if Apache is bad configured and doesn’t process
    your .htaccess or .php (or what else) scripts and gives up your
    database passwords, APIs keys, etc?
    • It’s not a safe approach to security
    • Solution: public/ with only a index.php requiring the application
    outside of the root public directory.
    79
    Tuesday, July 31, 12

    View Slide

  80. php.ini + production environment
    • error_reporting = E_ALL;
    Caveat: for PHP < 5.4 use E_ALL | E_STRICT instead (or: upgrade!)
    • log_errors = 1;
    • display_errors = 0;
    • Important: for development, you almost certainly want:
    display_errors = 1;
    unless you’re being a smart guy listening to the error log (i.e., with tail)
    80
    Tuesday, July 31, 12

    View Slide

  81. Deploying on the shared hosting
    • Common issues & disturbances:
    - Low performance
    - Security holes
    • PHP Suhosin (hardened php project) may be in use
    • Cheap & Dirty
    • You decide: it might be worth it
    81
    Tuesday, July 31, 12

    View Slide

  82. Deploying on the shared hosting
    • Sessions
    - storing on files? Don’t store on a public place like /tmp
    • A instance (“virtual machine”) on Amazon Web Services, Slicehost,
    Rackspace, or Linode is not that expensive and might be a better fit.
    82
    Tuesday, July 31, 12

    View Slide

  83. Fail-safe systems
    • failures will happen someday (it’s a fact)
    • graciously fail is less damaging than disasters
    • shared nothing architecture is a good approach
    • Minimize the number of single points of failure
    83
    Tuesday, July 31, 12

    View Slide

  84. What can cause a failure
    • Configuration
    • Database
    • Filesystem
    • APIs
    • Email systems
    • Sockets
    • Software
    • Releases
    • Hardware
    • Power outage
    • Network outage
    • ...
    84
    Tuesday, July 31, 12

    View Slide

  85. a:link, a:visited, etc.
    • Remember that, by default (HTML with no styling), a visited link gets a
    different color on most browsers?
    • Now what if you check if someone visited a given address?
    - this is a privacy breach
    - modern browsers are starting to work on fixing this
    • https://developer.mozilla.org/en/CSS/
    Privacy_and_the_:visited_selector
    85
    Tuesday, July 31, 12

    View Slide

  86. On Quality Assurance (QA)
    • It should be the goal of the developer that the QA find nothing wrong
    • The developer should deliver high quality work. The following helps:
    - Test-Driven Development (TDD)
    - Behavior-Driven Development (BDD)
    - Continuous Integration (CI)
    - unit tests, behavior testes, unit tests, integration tests
    - code versioning (git is the most prominent)
    - issues & bug tracking (i.e., JIRA, GitHub Issue Tracker, etc)
    86
    Tuesday, July 31, 12

    View Slide

  87. Physical security: not for granted
    • Lest We Remember: Cold Boot Attacks on Encryption Keys
    https://citp.princeton.edu/research/memory/
    http://www.youtube.com/watch?v=6EuUwDvlHz8
    • Payment Card Industry Data Security Standard (PCI DSS)
    https://www.pcisecuritystandards.org/security_standards/
    • Adventures with Daisy in Thunderbolt-DMA-land: Hacking Macs
    through the Thunderbolt interface
    http://www.breaknenter.org/2012/02/adventures-with-daisy-in-
    thunderbolt-dma-land-hacking-macs-through-the-thunderbolt-
    interface/
    87
    Tuesday, July 31, 12

    View Slide

  88. Never stop learning
    • The best way to build rock-solid secure apps
    • Read research papers
    • Be part of your local user group
    • Get involved with open source projects: push code on GitHub
    88
    Tuesday, July 31, 12

    View Slide

  89. Some good resources
    • Common Vulnerabilities and Exposureses (CVE) http://cve.mitre.org/
    The Open Web Application Security Project https://www.owasp.org/
    • Joind.in http://joind.in/ (talks organized by events, very useful)
    • Voices of the ElePHPant http://voicesoftheelephpant.com/
    89
    Tuesday, July 31, 12

    View Slide

  90. Some Images are from
    • http://www.flickr.com/photos/big-pao/186885653/
    • http://windowboyman.deviantart.com/art/Dangerous-cookies-163434282
    • http://www.flickr.com/photos/neldorling/2630809618/
    • http://www.codinghorror.com/blog/2008/08/protecting-your-cookies-httponly.html
    • http://anenglishwomaninsalem.com/2012/03/15/when-socially-awkward-people-get-invited-to-company-meetings/
    • http://www.flickr.com/photos/cookiecanvas/6662258619/
    90
    Tuesday, July 31, 12

    View Slide