State Transfer • Each request MUST be treated as unique • What is a request? Answer: each <verb> to any resource (i.e., image, text, script, redirect) Verbs: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, CONNECT, PATCH
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
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…)
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
distributed across multiple locations to deliver services and content more efﬁciently • 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*.staticﬂickr.com for ﬂickr.com fbcdn-sphotos-*-*.akamaihd.net
adopts doesn’t use “www.” on their links, so it avoids exchanging the application cookie for static assets requests, which has two beneﬁts: 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
a user session identiﬁer • 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
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
with the HttpOnly ﬂag 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://publicsufﬁx.org/ http://publicsufﬁx.org/list/effective_tld_names.dat but it has failed in the past
- 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.
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 conﬁdential unencrypted information: the proxy may strip the certiﬁcate for you like this: HTTP (you) <—> evil proxy <—> HTTPS (server) • The new HTTP Strict Transport Security mechanism tries to ﬁx it by including a blacklist on browsers of web address that MUST NOT use HTTP for communication
wi-ﬁ 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)
• Reduces the point of failure • Renders the man-in-the-middle attacks inefﬁcient • Renders the DNS poisoning attack (alone) inefﬁcient • TLS = evolution of SSL • Limitation: Limitation: no more than one validly certiﬁed secure web site on a IP due to the HTTPS protocol design. But this should change or IPv6 will ﬁx it sooner than later.
are different levels of certiﬁcates. • A certiﬁcate is (hopefully) signed by a recognized CA root certiﬁcate and checked against its invalidation list • A certiﬁcate can be self-signed (stupid, not recommended, and useful) • They have expiration dates
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 certiﬁcate belongs to (don’t you?)
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 certiﬁcates for them • You’d have to read the certiﬁcate document each time before allowing your browser to send sensitive data (session IDs, anyone?) to the requesting server: not gonna happen.
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)
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)
sequences is also a headache • Byte order mark (may show like “ï»¿”) on top of your PHP ﬁles 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
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.
data (post-ﬁltered) 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 ﬁltered and unﬁltered data
- ﬁrst 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
- MySQL is way more permissive (in the bad sense) than Postgresql - try to add “test” to a char(2) ﬁeld on a MySQL DB: - it will save “te”, Postgresql would fail emitting a notice that the data is larger than the space of the ﬁeld. • Don’t take external APIs data for granted, take the same care with them as you would with user input data
to protect it yourself • It doesn’t carry the concept of different databases. A preﬁx in the key part will sufﬁce to ﬁx this limitation: - e.g., keys: session_S929JDLRJ223, cache_page_index, proﬁle_henvic • By default, it allows connection from any client with no authentication. SASL might be used. Strict ﬁrewall rules are advised. Sadly many memcached installs on production environments are unprotected.
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
methods - compute-intensive actions triggered by the ﬁnal 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)
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.
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
/ 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" + ﬁnd another way to do so + etc • Really? Isn’t the case for a hidden ﬁeld in a form or something better?
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/<project> /index.php /.htaccess /lib/.htaccess ...
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 ﬁxing this • https://developer.mozilla.org/en/CSS/Privacy_and_the_:visited_selector
of the developer that the QA ﬁnd 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)
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/