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
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
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…)
• 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
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
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
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
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
• 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
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.
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
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)
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.
• 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).
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?)
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.
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).
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?”
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)
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
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
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.
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
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)
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)
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/
henvic
kypkyp
clown0082
ari_mharada
m_coder
jxmtst
uhooi
tonkotsuboy_com
slsops
mitchan
taowata
psj59129
hpgrahsl
chrisshort
iamctodd
afnizarnur
3n
lauravandoore
pedronauck
jensimmons
maltzj
gr2m
trishagee
caitiem20
chrislema