Thursday, July 30, 2015Cross-Site Scripting (XSS) is a vulnerability I personally spend a lot of time researching and writing about. This is largely due to the fact that XSS is EVERYWHERE!
Thursday, July 16, 2015The Go language released its Go 1.5 beta early last week with a host of new features: a self-hosted compiler, concurrent garbage collection, multiprocess usage for goroutines (equaling the number of cores on your system), and more. We last covered Go almost a year ago when we discussed some of the benefits of the language, like UTF-8 strings, concurrency with the CSP model, and superb performance.
With Go 1.5's changes in mind, it's worth taking a look at some of the security issues in Go applications to see how they fare. What kinds of concurrency issues emerge and what do they mean for web security?
Thursday, July 9, 2015Welcome to the next edition of the Intro to BurpSuite series. This time around I wanted to draw attention to one of the more advanced features of the BurpSuite toolset, Burp's built-in sequencer. The Sequencer tool has a lot to offer, but it is often overlooked and seen as a complex instrument to be used by only the most intelligent security engineers. If you've been following along in the series and have a few application assessments under your belt, this is a good addition to your mental toolkit to expand your capabilities as a security analyst or penetration tester.
Thursday, June 25, 2015Username enumeration is one of those vulnerabilities that appear to be everywhere. Facebook has it, Twitter has it, and basically every default Wordpress installation has it. Companies don't appear to see the risk associated with the vulnerability.
Monday, June 22, 2015In 2014, I gave a talk at RailsConf that touched on some problems I've come to experience with the opinions that Rails employs to achieve its "convenient" APIs. One part of the talk described something I really wanted to see, which was a sane attribute API. Well, Sean Griffin started working on one not long after that talk. It'll be "official" in Rails 5, but it's in Rails 4.2 and is already being used under the hood by your apps today—it's just missing documentation.
If you've ever tried doing something as simple as overriding attribute accessors and found yourself chasing down and plugging endless edge cases, this post is for you.
Thursday, June 18, 2015Since we last visited Grails (and Grails.nV), the Grails project has updated to a new major version (3.x) that comes with a host of performance improvements, Gradle support, and security enhancements. With these changes, it is a good time to revisit the project.
For Grails applications, one topic that needs attention is the use of static analysis to identify common security vulnerabilities. If developers have access to effective automated tools that alert of security concerns during development, these problems can be fixed before the code is released. Furthermore, these tools reveal issues in large and well-established codebases by automating the code checks performed during code promotion. For example, tracing tainted variables or variables influenced by user-provided input shows the impact of unchecked user input through an application. Stored XSS or SQLi are simple to detect in a majority of cases.
There are currently only two static analysis tools that provide coverage for Groovy: IntelliJ IDEA's built-in debugger and CodeNarc, an open-source static analysis tool. Since it is not reliant on a single development interface, this post will examine CodeNarc.
Wednesday, June 17, 2015Ah, 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.
Before we begin: do not leverage these techniques against a system unless you have the express permission of the system owner. nVisium is not liable for any trouble you get into not using common sense. Now, with that out of the way, let's dive in.