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
Tweet

More Decks by Henrique Vicente

Other Decks in Programming

Transcript

  1. HTTP and Internet security
    Henrique Vicente

    View 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,
    redirect)


    Verbs: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS,
    CONNECT, PATCH

    View 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 Slide

  4. View Slide

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

  6. HTTP is a textual protocol
    response
    body
    …

    …


    response
    header
    request header
    request header
    no request body for this request

    View Slide

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

    http://www.catb.org/esr/writings/taoup/html/ch05s01.html
    • Less compact than binary (or is it?)
    • More easily adaptable (WebSockets, SPDY, HTTP 2, QUIC…)

    View Slide

  8. First request to the server

    View Slide

  9. Browsers sends the

    cookie back to the server

    View Slide

  10. View Slide

  11. • 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
    subdomains
    • It’d be against the rules of PCI DSS:

    Payment Card Industry

    Data Security Standard

    View Slide

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

    fbcdn-sphotos-*-*.akamaihd.net

    View Slide

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

  14. What do you usually store in authentication
    cookies?
    • 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 Slide

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

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

    http://publicsuffix.org/

    http://publicsuffix.org/list/effective_tld_names.dat

    but it has failed in the past

    View Slide

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

    View Slide

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

    View Slide

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

  20. 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
    information:


    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 Slide

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

  22. HTTPS = HTTP + SSL/TLS
    • 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 Slide

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

    View Slide

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

    - VeriSign

    - Thawte

    - RSA Security

    - Cisco

    - AOL Time Warner

    - (many others...)

    View Slide

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

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

    View Slide

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

    View Slide

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

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

    View Slide

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

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

    - Don’t.


    View Slide

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

    • insecure

    • complicated, prone to errors

    • …

    View Slide

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

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

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

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

    • you must adopt UTF-8 or you lose consumers

    • however...

    View Slide

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

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

    View Slide

  39. 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?”

    or

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


    anyone...?


    May happen with other scripting languages as well

    View Slide

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

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

    View Slide

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

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

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

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

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

  47. Use prepared statements
    • Better performance

    • Easy way to escape things the right way

    View Slide

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

  49. Storing passwords: don’t

    View Slide

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

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

  52. A Future-Adaptable Password
    Scheme

    View Slide

  53. bcrypt
    The original implementation was for OpenBSD

    View Slide

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

    • Rainbow tables are impossible

    View Slide

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

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

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

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

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

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

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

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

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

    ...

    View Slide

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

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

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

  67. What can cause a failure
    • Configuration

    • Database

    • Filesystem

    • APIs

    • Email systems

    • Sockets
    • Software

    • Releases

    • Hardware

    • Power outage

    • Network outage

    • ...

    View Slide

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

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

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

    View Slide

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

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

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

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

    View Slide