Missing server-side validation consistently scores a place in the OWASP Top 10. Browsers nowadays offer a lot of ways to easily implement client-side controls, increasing the usability by a lot. They automatically detect missing fields or invalid characters in your input fields and may even validate user input against a regular expressions.
However, these controls should only be considered as usability features. When sending data to a back-end system the application must always ensure data integrity by implementing encodings, validations and filters. Even for small applications this is a painful and tedious process. For each possible input, developers together with security experts have to carefully identify the context of each field, how the input is going to be used and what data requirements are present.
Furthermore, the application must always be aware of the current data encoding and apply the correct decoding before validating or filtering anything.
In this post we are going to present a new groundbreaking solution to combat missing server-side validation once and for all.
We recently identified a security issue in FireEye AX 5400, that also affected other products. We responsibly disclosed the bug to FireEye and a fix that addresses the issue has been released with version 7.7.7. The fix was also merged into the common core and is available as 8.0.1 for other products (i.e. FireEye EX).
I recently had the pleasure to attend two events organized by the Digital Society Institute, one was a workshop on software vulnerabilities and one was their annual conference. For both events I delivered input on the security of security products and their evaluation (slides can be found here). The DSI did a great job of assembling people from various areas (e.g. industry, academia, politics, and research) so there was a lot of input which is not covered by conferences I usually attend. The workshop I attended also resulted in a short policy recommendation when it comes to the security of security products which can be found here.
Usually I’m not the kind of guy who talks about such economic topics. Because I’m an engineer / security researcher who is exclusively concerned with understanding technical problems and if possible, solving them accordingly. My whole education is based on this and contains predominantly technical aspects of information security. This sometimes makes it difficult to understand what the market cares about (and why some products are being developed / exist on the market 😉 ). Nevertheless, a current engagement for one of our customers made me stumble upon such a product.
We were involved in a test where a security appliance (a black box 😉 ) played the core role. As you might know, the test procedure generally depends on the security question to be answered. In this case the question to be answered was, whether the black box provides the promised information security benefit. More specifically, we took a look at the environment / infrastructure, the protocols and the systems around it and checked if the black box does its magic. So the black box itself wasn’t in direct focus of the test. We were quite amazed about the blind trust the product received (but what else can one do, but trust the device they have already purchased ;-)? You can analyze it and that is what we did. Continue reading “How ‘security’ black boxes might corrupt your investment”
This is a guest post from Vladimir Wolstencroft, to provide some details of his upcoming #TR15 talk.
What do you get when you combine a security appliance vendor, a bug bounty program, readily available virtualised machines, a lack of understanding of best security practices and broken crypto?
Ownage, a good story and maybe even that bounty…