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

HTTP and Internet Security

HTTP and Internet Security

This is a tech talk I gave at my workplace. It's basically my past talk with some partial improvements.

Henrique Vicente

March 27, 2014

More Decks by Henrique Vicente

Other Decks in Programming


  1. HTTP and Internet security
    Henrique Vicente

    View full-size slide

  2. HTTP: stateless
    • HTTP is a RESTful protocol:

    REST: Representational State Transfer
    • Each request MUST be treated as unique
    • What is a request?

    Answer: each to any resource (i.e., image, text, script,


    View full-size slide

  3. HTTP request / response messages
    • The request/response message consists of the following:
    • Request line, such as GET /logo.gif HTTP/1.1 or Status line, such as
    HTTP/1.1 200 OK,
    • Headers
    • An empty line
    • Optional HTTP message body data
    • From http://en.wikipedia.org/wiki/HTTP_body_data

    View full-size slide

  4. What about SPDY, HTTP 2, QUIC
    • Today we’re at HTTP/1.1
    • Some large web sites are playing with SPDY and QUIC

    for better performance

    View full-size slide

  5. HTTP is a textual protocol


    request header
    request header
    no request body for this request

    View full-size slide

  6. Advantages and drawbacks of a textual protocol
    • Easy for human beings to read, write, and edit without specialized

    • Less compact than binary (or is it?)
    • More easily adaptable (WebSockets, SPDY, HTTP 2, QUIC…)

    View full-size slide

  7. First request to the server

    View full-size slide

  8. Browsers sends the

    cookie back to the server

    View full-size slide

  9. • Cookies were not designed with security in mind
    • You’ve to make careful use of this technology
    • Example:

    University lets their students and professores have their own web pages at
    example.edu/~user and a library store at

    store.example.edu: even if no member of the academy has intention to do
    harm this would be dangerous since you can read/write cookies for
    • It’d be against the rules of PCI DSS:

    Payment Card Industry

    Data Security Standard

    View full-size slide

  10. Cloud computing / Content
    Delivery Network
    • Collection of servers distributed
    across multiple locations to
    deliver services and content
    more efficiently
    • lower latency
    • higher data transfer speeds
    • reliability
    • more resilience to disasters and
    attacks: both physical and virtual
    some you may recognize

    a*.twimg.com for twitter.com
    th*.deviantart.net for deviantart.com
    farm*.staticflickr.com for flickr.com


    View full-size slide

  11. Why the different domains?
    • Principle of least privilege

    Twitter adopts doesn’t use “www.” on their links, so it avoids
    exchanging the application cookie for static assets requests, which
    has two benefits:

    a) avoids overhead

    b) less security risks are involved
    • The trade-off is just a additional DNS-lookup
    • You can request more content at once if you request them from
    different domains at once, due to browser limits

    View full-size slide

  12. What do you usually store in authentication
    • Hopefully, a user session identifier
    • If you store the user’s password you’re doing it wrong
    • But before continuing:

    Never use http://example/?SESSION_ID=faf151515

    URI parameters are evil:

    Prone to unintentional disclosure and other risks

    - If you see anything like SID= or session_id= on the URI params chances are the
    page you’re accessing is compromised

    And POST-based sessions is a horrible workaround and breaks the REST
    paradigm, don’t use it

    View full-size slide

  13. Using authentication cookies the right way
    • Avoid session fixation issue

    Never trust a cookie NOT created by the server: if the server ever
    receives a authentication cookie value it doesn’t recognize it must
    be destroyed and a new one created to replace it

    Regenerate your authentication session when the user logs in

    View full-size slide

  14. • Learn how to use things like setting the cookie with the HttpOnly
    flag and what it is for (helps in avoiding XSS attacks from
    hijacking your cookies due to a bad implemented HTML sanitizer
    for user content, etc), HTTPS-only cookies, etc
    • Supercookies: if www.example.com can

    read/write a cookie for example.com, why

    can’t it write for .com?

    Answer: there’s a blacklist



    but it has failed in the past

    View full-size slide

  15. 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

    View full-size slide

  16. Privacy concern: Zoombie cookie
    • localStorage, evil extensions, and
    so on
    • when the cookie gets erased, it is
    • Please, don’t be evil.

    View full-size slide

  17. How DNS works
    • Shared-nothing architecture: decentralized / no SPOF - single point of failure
    • Root servers
    • Many servers all over the world…
    • When solve a name to a IP address

    (or more) or another name (cname)…
    • You can solve a name based on service: HTTP, mail, samba, or…
    • Geolocation, available resources, load balancing, etc.

    View full-size slide

  18. DNS cache poisoning
    • A“rogue” DNS server may contain wrong information:

    this may happen either by mistake or intentionally
    • This may cause Denial-of-Service or cause your system to route data
    trough a transparent proxy to intercept confidential unencrypted

    the proxy may strip the certificate for you like this:

    HTTP (you) <—> evil proxy <—> HTTPS (server)
    • The new HTTP Strict Transport Security mechanism tries to fix it by
    including a blacklist on browsers of web address that MUST NOT use HTTP
    for communication

    View full-size slide

  19. HTTP on wireless networks
    • If you use a shared wi-fi network with shared passphrase anyone
    that has access to it can see what data is being transferred
    • If you don’t use a passphrase, anyone nearby can access what data
    is being transfered
    • You still have to deal with making sure to use WPA 2 the right way,
    with WPS disabled, and so on… (we take it for granted and, yeap,
    usually this is enough)

    View full-size slide

    • A combination of protocols
    • Reduces the point of failure
    • Renders the man-in-the-middle attacks inefficient
    • Renders the DNS poisoning attack (alone) inefficient
    • TLS = evolution of SSL
    • Limitation: Limitation: no more than one validly certified secure web site on
    a IP due to the HTTPS protocol design. But this should change or IPv6 will
    fix it sooner than later.

    View full-size slide

  21. • Keep in mind: you are using a secure protocol for a reason
    • This means: your JavaScript, CSS, and images should also use
    • 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

    View full-size slide

  22. How the HTTPS protocol works
    • We have Certificate Authorities (CAs):

    - VeriSign

    - Thawte

    - RSA Security

    - Cisco

    - AOL Time Warner

    - (many others...)

    View full-size slide

  23. 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

    View full-size slide

  24. About certificates
    • Not every certificate is the same. There are different levels of

    • 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

    View full-size slide

  25. Extended Validation (EV)
    • Extensive verification of
    identity before emitting
    the certificate to the

    • No more secure than a
    non-EV certificate

    • Might make part of your
    address bar green, etc.

    View full-size slide

  26. 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?)

    View full-size slide

  27. Certificates for intranet
    • If you have a certificate for http://secret-docs.intranet/ you’re doing it

    - 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.

    View full-size slide

  28. 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).

    View full-size slide

  29. Deploying your website or app
    • Are you still using FTP?

    - Don’t.

    View full-size slide

  30. FTP is… just don’t use it
    • really slow

    • insecure

    • complicated, prone to errors

    • …

    View full-size slide

  31. 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)

    View full-size slide

  32. 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.

    View full-size slide

  33. 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

    View full-size slide

  34. Text Encoding
    • UTF-8 is here to stay

    • you must adopt UTF-8 or you lose consumers

    • however...

    View full-size slide

  35. 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)

    View full-size slide

  36. txt.evihcra.exe = exe.archive.txt?
    • UTF-8 has tricky control characters like one which shows the text

    • for example: it might make someone execute a file thinking it is just a
    text file, when it actually is a binary one

    View full-size slide

  37. UTF-8 is tricky
    • bad encoded UTF-8 with invalid byte sequences is also a headache

    • Byte order mark (may show like “”) on top of your PHP files makes
    you insane:

    - “how come the headers are already sent?”


    - “why is this JSON invalid in this browser and not in that one?”


    May happen with other scripting languages as well

    View full-size slide

  38. 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.

    View full-size slide

  39. User input data
    • Always filter and validate each data entry

    View full-size slide

  40. 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.

    View full-size slide

  41. 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)

    • Avoid mixing filtered and unfiltered data

    View full-size slide

  42. Filtered data != escaped data
    • Take a whitelist approach (rather than a blacklist one):

    - be awared: parsing HTML is more complicated than it seems to be

    • Use a solid parser! Don’t try to create one!

    View full-size slide

  43. Sanitize on input, escape on output
    • 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

    View full-size slide

  44. 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

    View full-size slide

  45. Use prepared statements
    • Better performance

    • Easy way to escape things the right way

    View full-size slide

  46. memcached caveats
    • No security out of the box: you’ve to protect it yourself

    • 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.

    View full-size slide

  47. Storing passwords: don’t

    View full-size slide

  48. 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

    View full-size slide

  49. 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

    View full-size slide

  50. A Future-Adaptable Password

    View full-size slide

  51. bcrypt
    The original implementation was for OpenBSD

    View full-size slide

  52. bcrypt
    • You can increase the iterations needed to calculate if a password
    matches with a given hash

    • Rainbow tables are impossible

    View full-size slide

  53. 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

    View full-size slide

  54. 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)

    View full-size slide

  55. 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.

    View full-size slide

  56. 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

    View full-size slide

  57. • 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

    View full-size slide

  58. 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

    View full-size slide

  59. 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?

    View full-size slide

  60. 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)

    View full-size slide

  61. 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/





    View full-size slide

  62. Deploying on the shared hosting
    • Common issues & disturbances:

    - Low performance

    - Security holes

    • Cheap & Dirty

    • You decide: it might be worth it

    • Static files? Great!

    View full-size slide

  63. 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.

    View full-size slide

  64. 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

    View full-size slide

  65. What can cause a failure
    • Configuration

    • Database

    • Filesystem

    • APIs

    • Email systems

    • Sockets
    • Software

    • Releases

    • Hardware

    • Power outage

    • Network outage

    • ...

    View full-size slide

  66. 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

    View full-size slide

  67. 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)

    View full-size slide

  68. Physical security: not for granted
    • Lest We Remember: Cold Boot Attacks on Encryption Keys



    • Payment Card Industry Data Security Standard (PCI DSS)


    • Adventures with Daisy in Thunderbolt-DMA-land: Hacking Macs
    through the Thunderbolt interface


    View full-size slide

  69. 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

    View full-size slide

  70. 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/

    View full-size slide

  71. 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/

    View full-size slide

  72. • http://artjumble.blogspot.com.br/2010/08/real-cookie-monster.html

    View full-size slide