80 engineers, 150 deploys every week, sometimes several hundreds of AWS instances. In a startup environment maintaining a high level of security is a challenging task. Concepts, codebase and infrastructure are changing rapidly. We trust our fellow engineers, the languages they choose and the machines they fire up at their will. Fear of making mistakes can squash innovation and creativity. With that in mind we are continuously developing automated tools which detect risky changes without blocking anyone but make it possible to react quickly. We will go into details describing our methods and tools to detect changes which might lead to security issues. Be this change in our AWS infrastructure, in our codebase or at the OS level.
Apart from the automated tools, we try to find other scalable ways of detecting issues. This is one of the main reasons we have launched our bug bounty program six months ago. The 100 submissions we got every month in average is a great indicator where we should improve the most. Besides fixing the issue itself we can use them as vulnerability patterns for our tools. This way we try to make sure that we are learning from our mistakes and we catch similar issues in the future as soon as possible. We would like to share our learnings – both personal and professional – which can be useful for other companies thinking about starting a bug bounty program.
All in all we believe we are not the only ones facing similar challenges, so we would like to share our experience.
7. Pre-CORS
●
Many different hacks
●
Proxy in same-origin
●
JSON-P
<script type="application/javascript"
src="http://server2.example.com/Users/1234?
jsonp=parseResponse">
</script>
HTML code:
parseResponse({"Name": "Foo", "Id": 1234, "Rank": 7});
Response Content:
8. How CORS works?
●
2 different request types:
– Simple request
– Not simple request
●
Browser makes the decision
9. The trick – simple request
Simple Request:Simple Request:
●
HEAD,GET or POST
●
Headers:
– Accept
– Accept-Language
– Content-Language
– Last-Event-ID
– Content-Type, but only if the value is
one of:
●
application/x-www-form-urlencoded
●
multipart/form-data
●
text/plain
24. Limitations: Write only requests
XmlHttpResponse is not readable if:
●
No Access-Control-Allow-Origins header
●
Source origin is not allowed in A-C-Allow-
Origins
●
WithCredentials is true but A-C-A-O=*
Bear in mind: the requests are still sent!
25. Limitations: Preflight Req Fails
If one of the requirements of the pre-flight
request is not satisfied, the original request will
not be sent.
OPTIONS /cors HTTP/1.1
Origin: http://api.bob.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header
Host: api.alice.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0
26. Solution
●
More awareness on the basics of CORS
●
Strict Allow-Origin settings
●
Rejecting Allow-Credential requests
●
Change of mindset: development problem
29. Hardening: Application
Application logic should consider CORS and
set the appropriate headers.
i.e.: ASP .NET:
Response.AppendHeader(
"Access-Control-Allow-Origin",
"example.com");