Ah, SQL injection. Probably one of the most iconic vulnerabilities in the web appsec sphere. Even given how easy it is to fix (parameterize your queries please, none of this blacklisting garbage), it’s still found in the wild on a regular basis. While there are a million posts out there detailing vanilla exploitation, this post is going to delve into more advanced attacks. Specifically, I’m going to discuss enumerating the schema of a database in a single payload, greatly reducing the number of queries required to exfiltrate data via bit shifting, and viable attacks in a blind and asynchronous situation. The focus will revolve around a SQL Server context, but most if not all of these techniques should transfer to exploitation of other databases.

This blog post will attempt to explain how Rails applications can protect themselves from Cross-Site Request Forgery (CSRF) by looking at the details of the built-in protection mechanisms.

With the holiday season in full swing, more folks are shopping online than any other time of the year. With the recent breaches of Target and Home Depot, many consumers are beginning to understand the need for exercising caution when shopping online.

In my last post, I identified security requirements that need to be addressed in any software development project. These requirements are important to building a more secure application. This post will discuss several techniques that are useful in eliciting the security requirements information. My last post in this series will discuss techniques that can be used in the design phase to design a more secure application.

When performing an application security assessment, one of the things we look for are sensitive secrets committed to source control. Most web applications rely on secrets to perform security operations. Those secrets could include API keys, database credentials, third-party service credentials, encryption keys, and more. The disclosure of these secrets could lead to unauthorized third-party service access or even complete system compromise.

nVisium is proud to announce the release of Django.nV, an intentionally vulnerable project management application. As with all of the ‘nV’ suite of applications, Django.nV demonstrates a series of common vulnerabilities in the context of a modern application. The flaws within the application include vulnerabilities ranging from the OWASP Top 10 (Injection, Insecure Direct Object Reference) to some Django-specific issues (Mass Assignment and Insecure Settings).

For the second time in a few months I had a conversation with friends on this Fortify finding - Privacy Violation: Heap Inspection.

By 2019, there will be half a billion wearable devices in use every single day. These wearable devices track everything from your heart rate, number of steps taken, distance you have traveled, GPS locations, insulin levels, etc. Wearable security encompasses many facets of security, and includes the security of other devices and communication protocols. Device security, application security, and network security all play an important role in the overall security posture of said wearables.