By Angie Chang (VP Strategic Partnerships, Hackbright Academy)
Thanks to NCC Group (home of iSEC Partners and Domain Services) in downtown San Francisco for hosting Hackbright alumni, students and mentors for an enlightening evening of lightning talks on security engineering!
Web Application Security 101
Rachel Engel, security consultant at iSEC Partners, spoke first about breaking into computers for a living. She started out by talking about security in the 1990s, when “everything was written in C” and nobody accommodated for buffer overflow. “If you could program back then, you could break into systems easily,” said Rachel.
With a buffer overflow, someone could run whatever program they wanted in your computer – and it was rampant back then. There were other problems like rlogin/rsh (unencrypted login) or when the protocol relied on the client no lying about the hostname and port. Firewalls keep people not already inside your network from connecting to internal computers. Anti-virus protected you from viruses not clever enough to evade the antivirus software, an protects you.
The first to make a model for application security in the 90s were “the lopht” which grew into a company called @stake — these are the forefathers of much the application security industry.
Today, you no longer have to breach networks to steal data – you can do it from the privacy of your web browser (XSS, SQLi, CSRF, Direct Object Reference, XML Injection). For example, “XSS” means that using your bank website with a XSS problem makes you vulnerable to an attack. Someone can log in as you, as a cross-side scripting bug lets someone other than you rewrite the HTML and JS on the page from somewhere else completely, by sending you a link or a web form. A “SQLi” is a SQL injection, which you can do remotely from a webpage.
You can also cause problems with web services frameworks, phone apps, operating systems, network protocols… these are all things you can find computer security holes in.
Rachel says, “It’s terrifying how easily you can find these bugs. We go onsite to companies, break into their websites and tell them where the holes are. You can’t really secure computer networks. If someone tells you something’s secure, you can secure individual applications but you can’t be absolutely safe you are on the network (but you can safely use applications on your network).”
This is why it’s application security, not Internet security 🙂
Take for example the coffee shops today. Everyone types the WiFi password into the field, but everyone accesses the network with the same password so everyone is sharing the same IP address and can look into each other’s information. So don’t access your bank on the WiFI at your local coffee shop!
You can’t secure networks but you can secure applications (for the most part) with:
– TLS
– Authentication
– Input validation
– Output encoding
– Anti-CSRF protection
What Rachel likes about security is that you touch every aspect of computer programming. You can learn about hardware, cryptography, every programming language under the sun. Any new technology that comes out always has security flaws to them.
Every company has quality assurance testers. Security bugs are just bugs, but they are just kinda very specialized bugs.
Security engineers and consultants get to work on new technology that comes out, which is fun!
How To Get Started With Security Engineering
If you are interested in security, try penetrating testing (or “pen testing”) web apps. Check out OWASP.ORG (open software security community). For example, try Fiddler and Burp proxy to break into a Flask web app. Download either one of these. There is a Python class that will let you send the POST request. If you send a post request with the right two parameters to the login page, it will let you guess passwords – then you type in as many passwords as you can get. Make sure you get permission from the server owner before you try.
History Of SSL/TLS
Katherine McKinley is a security architect at Netflix and a mentor at Hackbright Academy. She’s also a former iSECer, former Domain Svcs. She talks the history of TLS and SSL to Hackbrights – in 1991, Tim Berners-Lee created HTTP and invented the WWW: port 80 rendered in your browser but to create a website that accepts credit cards, you need to secure it somehow. SSL was invented by Netscape in 1994 and version 2 in 1995 was not very good, and Netscape keeps releasing new versions to introduce new encryption methods and get rid of old issues (ie. old hash methods that are broken).
SSL guarantees authentication. When you go to a website and you see the little green lock, you know you are talking to who you think you are. Data confidentiality and integrity (no changing of the information) are considered.
Cryptography is an advanced topic and takes a lot of time for people to become an expert. Public key cryptography. Authentication. Certificate pinning. PKI.
Kate talks about the importance of guaranteeing the integrity of communication. Maybe this is through a hash function or authenticated communication. Some forms are known to be broken (MD5, SHA-1) and SHA-256 and above are believed to be secure.
What is a TLS handshake? It does a couple of things – authenticate the server, authenticate the client, and agree how we protect our communication.
What TLS doesn’t protect is your IP address, your port numbers, the amount of communication or how long you’ve communicated or any lower level network attacks or application layer attacks or against phishing. If you have external APIs you may want to use it there, as well as database connections, email…
Bottom line: Use TLS 1.2 as much as possible!
If you are going to run a server, you will have to purchase a certificate – to know what server you are putting the certificate on, and have to prove you own the domain.
For the final slide in her presentation, Kate had everyone look at the Pandora login page for a possible security vulnerability. Everyone looked at it and guessed… but the main vulnerability is that the signin page has been served over HTTP – meaning, they can take your credentials and send it somewhere else before they log you in.
API Security
Astha Singhal, a senior product security engineer at Salesforce.com, works with product teams from design to implementation to help them build secure applications for Salesforce customers. She does pen testing once engineers are done writing the code, and helps teach the developers to be more secure with their code.
Astha stresses building secure APIs. First, an API is when you want to expose an interface to communicate with your web app. For example, Facebook wrote a developer API because they want people to build cool apps for Facebook. You expose these API interfaces to build custom integrations. You don’t have to worry about the presentation layer.
What does building secure APIs mean? No cross side scripting in the presentation layer… almost.
There are protocols to build APIs:
(1) SOAP – Simple Object Access Protocol is a protocol specification for exchanging structured information in the implementation of web services. Uses the XML message format and relies on another transfer protocol (like HTTP) for transmission.
(2) REST – Representational State Transfer is a means of expressing specific entities in a system by URL path elements. Allows interaction with a web-based system via simplified URLs. No POST body required.
Always do input validation. You cannot trust your users!
Always do whitelist filtering. Make sure to build secure whitelists for limiting the inputs, and don’t rely on blacklist filtering (someone can always find a way around your blacklist).
Validate incoming content types. The server should make sure the request content matches the specified content type header, and reject unexpected Content type headers.
Maintain least privilege. Don’t give anyone any more rights they need to do their jobs. This rule applies to everything in security – figure out the minimum possible permissions someone needs. This limits exposure.
Make sure to always secure your data in transit by using HTTPS. To test server configurations (because you want your web server to have up-to-date SSL configurations), try ssllabs.com/ssltest/index.html.
Working With Product Management
Jennifer Liou, Product Manager at NCC Group Domain Services (.trust gTLD), also gave a talk on Product Management.
This talk aimed to help set a good foundation for the relationship between Developers and Product Managers, as well as provide a guideline for those who might consider going into Product Management later on in their careers.
