Common Web Security Issues and Tips on How to Overcome Them

Slide 1

Slide 1 text

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 henriquevicente@gmail.com 1 Tuesday, July 31, 12

Slide 2

Slide 2 text

First web server 2 Tuesday, July 31, 12

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Cookies 4 Tuesday, July 31, 12

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

6 Tuesday, July 31, 12

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

Herd of elePHPants 12 Tuesday, July 31, 12

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

Securing your sessions • Session ﬁxation 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

Slide 18

Slide 18 text

Prevent session ﬁxation • Don’t reuse sessions. After any signiﬁcant 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

Slide 19

Slide 19 text

More on session hijacking • Set-Cookie with the HttpOnly ﬂag 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

Slide 20

Slide 20 text

Supercookie 20 Tuesday, July 31, 12

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

Zombie cookie 23 Tuesday, July 31, 12

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

Snifﬁng: 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-ﬁ hotspot on your preferred café? 28 Tuesday, July 31, 12

Slide 29

Slide 29 text

Snifﬁng: eavesdropping • Wi-ﬁ 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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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 ﬁles associated with your system (not part of the layout). 32 Tuesday, July 31, 12

Slide 33

Slide 33 text

Secure cookie • Set-Cookie with the Secure ﬂag (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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

Certiﬁcates • 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 certiﬁcate belongs to (don’t you?) 38 Tuesday, July 31, 12

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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 certiﬁcates which you don’t want to trust). 40 Tuesday, July 31, 12

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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 ﬁle thinking it is just a text ﬁle, when it actually is a binary one 48 Tuesday, July 31, 12

Slide 49

Slide 49 text

UTF-8 is tricky • bad encoded UTF-8 with invalid byte sequences is also a headache • Byte order mark (“ï»¿”) 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...? 49 Tuesday, July 31, 12

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

What a ﬁlter 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

Slide 53

Slide 53 text

What a validator should do • Checks if the given 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) 53 Tuesday, July 31, 12

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

Sanitize on input, escape on output • Take a whitelist approach (rather than a blacklist one): - parsing HTML is more complicated than what seems. - HtmlPuriﬁer 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 - ﬁ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 56 Tuesday, July 31, 12

Slide 57

Slide 57 text

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) ﬁ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 57 Tuesday, July 31, 12

Slide 58

Slide 58 text

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 ﬁle 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, ﬁx it anyways. More on https://github.com/henvic/MediaLab/issues/9 58 Tuesday, July 31, 12

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

Brute-force attacks • Doors to Denial-of-service - compute-intensive password hashing 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) 69 Tuesday, July 31, 12

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

• 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

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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" + ﬁnd another way to do so + etc • Really? Isn’t the case for a hidden ﬁeld in a form or something better? 75 Tuesday, July 31, 12

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

PHP(?), Apache and .htaccess • You don’t want your application and credentials accessible for the external world: what if Apache is bad conﬁgured 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

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

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

Slide 82

Slide 82 text

Deploying on the shared hosting • Sessions - storing on ﬁles? 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 ﬁt. 82 Tuesday, July 31, 12

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

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 ﬁxing this • https://developer.mozilla.org/en/CSS/ Privacy_and_the_:visited_selector 85 Tuesday, July 31, 12

Slide 86

Slide 86 text

On Quality Assurance (QA) • It should be the goal 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) 86 Tuesday, July 31, 12

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

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

Slide 90

Slide 90 text

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