Add Misc Talks

Author: loicteixeira

.gitignore

@@ -7,3 +7,4 @@
 # Nor these folders
 !Conferences/
 !Courses/
+!Talks/

Talks/10 ways to have a better conversation.md

@@ -0,0 +1,32 @@
+---
+url: https://www.ted.com/talks/celeste_headlee_10_ways_to_have_a_better_conversation
+---
+
+# 10 Ways to Have a Better Conversation
+
+## 1. Don't multitask. Be present.
+
+## 2. Don't pontificate
+> Everyone you'll ever meet will know something that you don't – Bill Nye
+
+## 3. Use open-ended questions
+
+## 4. Go with the flow.
+Let thoughts come out of your mind. Don't just hold on them and stop listening.
+
+## 5. If you don't know, say that you don't know.
+
+## 6. Don't equate your experience with theirs.
+They are never the same. All experiences are individual. It's not about yourself, conversations aren't an opportunity for self promotion.
+
+## 7. Do not repeat yourself
+Do not just rephrase your point multiple time
+
+## 8. Stay out of the weeds
+Forget the details
+
+## 9. Listen
+Listen with the intend to understand, not the itend to reply
+
+## 10. Be brief.
+> A good conversation is like a miniskirt, short enough to retain interest, but long enough to cover the subject.

Talks/How to have better political conversations.md

@@ -0,0 +1,9 @@
+---
+url: https://www.ted.com/talks/robb_willer_how_to_have_better_political_conversations
+---
+
+# How to have better political conversations
+
+- Both side don't cherish the same values.
+- When arguing with our own value, we are not asking the other to change their opinion, we are asking them to change their values.
+- We should adapt our message to use their values.

Talks/How to overcome our biases.md

@@ -0,0 +1,9 @@
+---
+url: https://www.ted.com/talks/verna_myers_how_to_overcome_our_biases_walk_boldly_toward_them
+---
+
+# How to overcome our biases? Walk boldly toward them
+
+1. Stop denial
+2. Walk towards them. To get comfortable, you'll first need to get uncomfortable
+3. Say it when someone is saying something wrong. This is the only way to stop the biases from perpetuating.

Talks/Introduction to Ruby on Rails security.md

@@ -0,0 +1,45 @@
+---
+url: https://youtu.be/Hez1QYc9yo8
+---
+
+# Introduction to Ruby on Rails security
+
+## SQL Injection
+> Nefarious SQL statements are inserted into an entry field for execution.
+
+- Don't build your query yourself, use the ORM which protects you. That being said, [some methods](http://rails-sqli.org/) are unsafe to use.
+- Don't solely rely on the ORM, consider setting users and permissions at the database level so even if someone gets access to the database via SQL Injection, they don't have full access to the database.
+
+## XSS
+> If an attacker adds a script and gets it to show to another user, he gets access to that user's session.
+
+- Variables within an html template are automatically escaped.
+- Variables used in a helper, within style/script blocks and in non-html templates **aren't** escaped. Use partials instead.
+- Whitelist URL from user. Don't blacklist, it's too easy to forget to add a URL to the list or for someone to find a URL which isn't blacklisted.
+- Consider CSP as an additional protection.
+
+## CSRF: Cross Site Request Forgery
+> Attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated.
+
+- Rails check tokens for `POST`, `PATCH`, `PUT` and `DELETE` actions but not for `HEAD` and `GET` actions. Therefore, you should never modify the state within `HEAD` and `GET` requests.
+
+## Direct Object Reference
+> Request a record by ID allow an attacker to guess and different record ID
+
+- Always scope under current user (e.g. `current_user.invoices.find(params[:id])` instead of `Invoice.find(params[:id])`) which not only will protect the resource, but will raise 404 instead of 403 (unauthorised), leaking the least possible amount of information.
+- Basically, filter first and query second.
+
+## Mass Assignment
+> A computer vulnerability where an active record pattern in a web application is abused to modify data items that the user should not normally be allowed to access such as password, granted permissions, or administrator status.
+
+Use [strong parameters](http://weblog.rubyonrails.org/2012/3/21/strong-parameters/) to prevent mass assignment.
+
+## Unexpected types
+`where` accepts a simple object or an array and use `=` or `IN` accordingly. Again, use strong parameters.
+
+## Arbitrary Objct Deserialisation
+YAML can contain artitrary ruby objects which can result in Remote Code Execution (RCE).
+
+## Gems to help
+- breakman: static analysis of security vulnerability for Rails app.
+- bundle-audit: check dependencies for know security issues.

Talks/OWASP Top 10 2013.md

@@ -0,0 +1,181 @@
+# OWASP Top 10 - Wellington Meetup 2016/11/29
+
+Notes from the Wellington meetup on November 29th 2016, discussing the OWASP Top 10  Edition 2013 (2017 is in draft at the time of writing).
+
+Check the [OWASP Top 10 Cheat Sheet](https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet) online for the latest version.
+
+Check the [DVWA](dvwa.org.nz) (Damn Vulnerable Web Application) which is specifically designed to teach vulnerabilities.
+
+## A1 - Injections
+
+Vulnerabilities:
+
+- Full Read/Write access to the DB.
+- Escalation of privileges.
+
+Prevention:
+
+- Use parameterises queries
+- Use your ORM
+
+Verify:
+
+- Put a `'` in your input fields. If it breaks, you're vulnerable.
+- Use [sqlmap](http://sqlmap.org/), an open source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and taking over of database servers.
+
+## A2 - Weak authentication and session management
+
+HTTP is stateless so we use cookies to remember who someone is.
+
+Vulnerabilities:
+
+- Credentials could be stored insecurely on the server.
+- Cookies can be guessed or stolen (control of session, logging in as another user)
+- General logic might be flawed.
+
+## A3 - XSS (Cross Site Scripting)
+
+Mixing untrusted data within a webpage. If an attacker can add its own script to a page, he can alter the way it behaves.
+
+Vulnerabilities:
+
+- Runs JS on the user's browser
+- Proxy commands through their computer
+- Trick them into performing an action
+- Redirect to phishing or malware
+
+Where:
+
+- HTML, when displaying user input on the page
+  - Form input
+  - URI parameters
+- CSS, when allowing a user to set custom colours
+- JS, when loading data
+- HTML attributes, escaping function aren't the same for single or double quotes (i.e. your escaping function should match what your front-end use)
+
+Prevention:
+
+- Don't display user input if possible, otherwise:
+  - Whitelist during input validation 
+  - Output encode all user supplied data.
+- See [OWASP XSS Prevention Check Sheet](www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet)
+- Set the right [CSP](https://content-security-policy.com/) (Content Security Policy) headers
+
+Verify:
+
+- Put a `<` in your input fields or url params which are later displayed. If it is shown unescaped, you are vulnerable.
+- Use [BeEF](http://beefproject.com/), a browser exploitation framework project.
+
+## A4 - Insecure Direct Object References
+
+Vulnerabilities:
+
+- Accessing objects you're not supposed to by modifying the URI attributes.
+
+Prevention:
+
+- Whitelist rather than blacklist. It's easier to maintain.
+- Don't trust user input
+- Verify permissions
+- Consider mapping database IDs to a temporaty ID per user (see ESAPI)
+
+## A5 - Security Misconfiguration
+
+Software, server platform out of date or misconfigured.
+
+## A6 - Sensitive Data Exposure
+
+Missing encryption allows man in the middle attack.
+
+Prevention:
+
+- Use HTTPS
+- Use [HSTS](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security)
+  - a web security policy mechanism which helps to protect websites against protocol downgrade attacks and cookie hijacking; it allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections,[1] and never via the insecure HTTP protocol 
+- Use [key pinning](https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning)
+  - a security mechanism which allows HTTPS websites to resist impersonation by attackers using mis-issued or otherwise fraudulent certificates.
+- Only collect what you need
+- Use standard strong algorithm
+- Generate, distribute and protect keys properly
+
+## A7 - Missing Function Level Access Control
+
+Failing to perform access checks on both client and server
+
+Prevention:
+- Do authorisation checks on `GET` and `POST`
+- Block functions from certain users
+- Users, role or claims-based permission.
+- Whitelist rather than blacklist.
+
+## A8 - Cross Site Request Forgery
+
+Forcing a user's browser to make a request.
+
+User access bad website which makes a request to target website and all credentials are passed through with the request
+
+Prevention:
+
+- Don't change data on `GET`, it should be idempotent
+- CSRF works when the attacker knows everything
+  - Include something unknown in the form like a CSRF token
+
+## A9 - Using Components with Known Vulnerabilities
+
+Out of date components
+
+Prevention:
+
+- Keep components up to date
+- Catalogue components you depend on
+- Follow security bulletins
+
+Verify:
+- [Retire.js](http://requirejs.org/) or [david](https://david-dm.org/) for JavaScript
+- Use `pip list --outdated` for Python
+
+## 10 - Unvalidated Redirects and Forwards
+
+Redirecting the browser to an unsafe url; typically, when using a `nextUrl` on a login page.
+
+Prevention:
+
+- Have a whitelist of what it is allowed to redirect to
+- Have regular expression to only allow internal urls
+
+# Frameworks
+
+Frameworks are a great way to migitate those risks as most of those issues have been resolved already.
+
+## How to choose a framework?
+
+- Choose a well known and well maintained (no abandonware) framework (it was originally phrased "something new" but we disagree with that)
+- Familiarise yourself with built-in protection
+- Build common code that new dev will leverage
+
+See [OWASP Framework Security Matrix](https://www.owasp.org/index.php/Category:Framework_Security_Matrix) (still WIP) to check what each framework protects you against.
+
+# Q&A
+
+
+## Is there a way to scan your application?
+
+There are some code scanners (like [Fortify](https://en.wikipedia.org/wiki/Fortify_Software)) but those solutions are usually expensive.
+
+Linters normally catch stylistic issues but might catch basic security issues as well.
+
+Use the [OWASP Zed Attack Proxy](https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project) to pentest your app.
+
+## User Input
+
+It is well known that you should trust user input and sanitise it.
+
+However, user input should be handled carefully even when it comes from your database. You might think that because it comes from the database it is safe, but you can never be too sure of how it was saved.
+
+## Browsers
+
+Vendors play their parts:
+
+- Key pinning was actually introduced by browsers.
+- The browser will block script that appears in the url and in the page.
+- From January 2017, Chrome will [flag non HTTPS pages with password or credit-card fields as non-secure](https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html).

Talks/The Future of Programming.md

@@ -0,0 +1,24 @@
+---
+url: https://vimeo.com/71278954
+---
+
+# The Future of Programming (by Bret Victor)
+
+> Technology changes quickly, people minds changes slowly. It can be easy to adopt new technology but hard to adopt new ways of thinking.
+
+> Ideas required people to unlearn what they've learned and learn to think in a new way and there's often a lot amount of resistence.
+
+Bret Victor runs the talk like it's the 70s, displaying his slides with a overhead projector, explaining the beggining of programming – coding procedures as text files in a sequential programming model — in a very satirical way, saying "it will never happen", which is exactly what happened.
+
+He showcases innovative ways of thinking/programming of that time:
+- Sketchpad 1962, give constraints to the computer which "figures this out" (e.g. not teaching how to draw a rectangle, but constraints some lines to be mutually perpendicular).
+- Planner 1969, explains a program by goals (which will become logic programming).
+- Regular Expressions 1967, pattern matching.
+
+It becomes apparent that like the binnary programmers who didn't want to learn assembly or Fortran in the 60s, we were (and are still) blind to those new ideas which fell into oblivion.
+
+He concludes that it would be a shame if 40 years later (i.e. 2010s) we were still doing the same, and suggest that we didn't learn anything from the past. But more importantly, it would be a shame if we had forgotten those ideas and the fact that we can have new ideas about programming. It would be a shame if this was what we teach new generation as they would essentially grow up with dogma, which is really hard to break out of it. Once again, he is giving a satirical look at today's world.
+
+> The most dangerous though you are gonna have as a creative person is to think that you know what you're doing, because [...] you stop looking around for other ways of doing things and you stop being able to see other ways of doing things.
+
+In the 60s-70s, nobody knew what programming was so they would try anything they could think of. We, as a field, have to admit we don't know what programming is so we can embrace new ideas.