Find more about me on:
  • googleplus
  • linkedin
  • skype
  • twitter
  • youtube

Here are my most recent posts

All posts by Dan Kuykendall

Dan Kuykendall is the founder and co-CEO at the premier application security solutions provider NT OBJECTives, Inc. Throughout his career, Dan has helped develop advanced dynamic application security testing software, a fundamental aspect to NT OBJECTives’ reputation as a leader in comprehensive web application scanning. Dan has also worked for McAfee’s Foundstone and Fortis, where he founded the U.S. Information Security team. Connect with Dan on Google+
Mobile Apps

How to Overcome the Shortfalls of Web Application Security Scanners when Testing Mobile & Rich Internet Applications

Mobile AppsYou’ve built a custom rich internet application that is sure to become your business’ next major revenue stream. Conscious of security, you’ve ensured that the native application authenticates to the server, and you’ve run the app through a web application security scanner to identify weaknesses in the code. Those vulnerabilities have been remediated, and now you’re ready to go live.

Not so fast.

Despite your best intentions, chances are good your rich internet application is going live with dangerous security flaws. Most traditional web application security scanners and authentication methods do not provide the necessary protection when you’re dealing with modern application architectures, data formats and other underlying technologies. However, you can still build state-of-the-art rich internet applications with reliable and safe web application security by following these simple steps.

Step 1: Understand your chosen technology and its security requirements.

Classic HTML applications are no challenge for web application security scanners because that’s what they were originally built to do. However, rich internet applications based on newer technologies like AJAX, JSON and REST are a different story –,most security scanners do not support these new formats unless they’ve been re-architected. Due to the heavy use of JavaScript or complete lack of HTML, these new application formats and technologies make it nearly impossible for scanners to crawl an app. Plus, mobile applications further complicate matters because they often use web services which cannot be crawled at all.

To make matters worse, attackers are finding new ways to exploit application programming interfaces (APIs) associated with mobile applications. Web application session management techniques fail to deliver the protection developers expect, and these old and insecure techniques do not stop attackers from tampering with the application, committing fraud or performing man-in-the-middle attacks.

Therefore, it is important to understand the technologies used in your rich internet applications so you can find an appropriate web application security scanner and/or supplement your scanning efforts accordingly. Below is a list of the technologies that may require a more in-depth security solution:

  • AJAX applications: JSON (JQuery), REST, GWT (Google WebToolkit)
  • Flash remoting: Action Message Format (AMF)
  • HTML5
  • Back end of mobile apps powered by JSON, REST and other custom formats
  • Web services: JSON, REST, XML-RPC, SOAP
  • Complex application workflows: Sequences (shopping cart and other strict processes) and XSRF/CSRF tokens

Step 2: Understand the vulnerabilities of rich internet applications.

There are two key qualities you should require of a web application security scanner that you plan to use for modern rich internet applications. The first is the ability to import proxy logs. The second is an understanding of mobile application traffic, which enables the scanner to create attacks to test for security flaws. Vendors are often quick to advertise their scanners’ ability to be fed data from a proxy, but if the scanner is not familiar with JSON and REST, it will not be able to create attack variations – even when fed recorded traffic.

Like web application security scanners, traditional authentication methods fail to deliver the protection they once promised. While historically used to protect server-side mobile applications from SQL injection and cross-site scripting attacks, today’s authentication methods simply aren’t sophisticated enough to provide adequate web application security to new rich internet applications and mobile apps. For example, attackers can exploit weak passwords when a scheme only authenticates the user and not the application. This can be avoided by using a client-side certificate to identify the application, but this isn’t feasible for all apps – especially customer-facing mobile apps.

Step 3: Determine whether your web application security scanner is capable.

You can – and should – ask your web application security scanner provider what technologies the tool is able to scan. But don’t leave it at that – verify what they say is true. For instance, you can test for the security scanning coverage of an AJAX application by analyzing the request/response traffic. To do so, simply enable the scanner’s detailed logging feature, run the scanner through a proxy like Paros, Burp or WebScarab, and save the logs for manual review.

JSON also poses a unique challenge to web application security scanners. They must be able to decipher the new format and insert attacks to test the security of web application interfaces. A review of detailed logs of request/response traffic will indicate whether the web application security scanner is fully capable of protecting rich internet applications like yours. However, not all web application security scanners provide detailed logging. If this is the case, you will need to set up a proxy to capture traffic during the scan. Begin by scanning only a page that uses JSON, then check to see if the scanner requests include the JSON traffic and requests.

Step 4: Bolster manual testing efforts and custom web application security models.

Attackers are increasingly targeting back-end servers. And while new mobile APIs like JSON create new ways to engage customers in rich internet applications, they also create new ways for attackers to reach back-end servers. The only way to discover and remediate API security flaws, authentication weaknesses, protocol-level bugs and load-processing bugs is with several rounds of testing. Also, understand that you cannot rely on SQL or basic authentication to protect the back end. Develop server-based applications to anticipate attacks by continually verifying the integrity of the application and uptime environment.

Finally, when developing rich mobile applications, keep the following tips in mind:

  • Data provided by the client should never be trusted.
  • A device’s mobile equipment identifier should never be used to authenticate a mobile application, but do use multiple techniques to verify that requests are from the intended user.
  • Because session tokens for mobile apps rarely expire, attackers can use them for a very long time.
  • Credentials should not be stored in the application’s data store, local to the device.
  • When requiring SSL, a valid certificate should be necessary.

Guaranteeing reliable web application security for rich internet applications and mobile apps can be tricky business. However, completing the proper research, choosing the right security scanner, and performing an ample amount of testing will help detect vulnerabilities and ward off new attacks, allowing your application to be successful in the marketplace.

Application Workflows

Web Application Security Testing for Complex Workflows. Not so Complex Anymore.

Conducting web application security testing for complex workflows can be a real pain. In order to find vulnerabilities, valid test data must be passed through exactly as the workflow prescribes. Most web application security testing scanners aren’t up for the job, so security testers must supplement their scans with manual testing.

If your organization has just a couple applications that aren’t changing, then manual testing may not be a big deal, but that’s rarely the case. Many large organizations have hundreds or thousands of web applications. Manually security testing all of them can be expensive and time consuming – requiring resources that your organization simply doesn’t have.

We understand, and have enhanced NTOSpider to address this pain point. Today, we announced that NTOSpider is now the first web application security testing scanner capable of understanding complex workflow sequences and the expected results, which enable it to automatically create relevant session states and find web application vulnerabilities. Bottom line: With NTOSpider, security teams can automate the security testing of complex workflows – saving a tremendous amount of time and finding more vulnerabilities sooner!

In order to understand the significance of NTOSpider’s update, it helps to understand how traditional scanners fail to test complex workflows. Most web application security testing scanners are built to conduct an assessment in two phases: a crawl phase and then an attack phase. During the crawl phase, the scanner gathers information about the application’s attack vectors. The scanner develops an understanding of the application’s landscape, including the pages and inputs on each page. Scanners then use the information gathered by the crawl to randomly attack pages.

Application Workflows

It’s best to attack most web application functionality randomly. However, this isn’t the case for complex workflows. In order to find vulnerabilities, valid test data must pass, in order, through the prescribed workflow. Attacking workflows at random isn’t effective. When the web application security testing scanner attempts to attack the shipping page without adding items to the cart, for example, the application generates an error without accepting the scanner’s attack, because there are no items in the cart. Unfortunately, the scanner is unaware of the error and misses vulnerabilities as a result.

Security testing the workflow in order is one important piece of the equation, but it’s also critical to test the entire workflow. Scanners, like hackers, submit various kinds of attacks. One kind of attack is SQL injection. In a SQL injection attack, the hacker or scanner enters a malicious SQL statement as an attack through the last name field instead of entering an actual last name. So, in this example, the malicious attack is entered through the ‘last name’ field on the billing form. The application then holds that data in temporary storage until the user confirms the order. It is not until the order is confirmed, that the information is sent to the database (SQL server) and the SQL vulnerability could be detected by the scanner. So, if complex workflows aren’t tested in their entirety vulnerabilities won’t be found, in this case, a vulnerability in the ‘last name’ field wouldn’t be found.

For these reasons, most web application security testing scanners are unable to effectively attack complex application workflows in their entirety and in the prescribed application workflow. Scanners need to be architected in a way that they can handle both kinds of security testing for complex workflows where both order and completeness are critical. NTOSpider understands and respects application workflows so that attack payloads are delivered into the application code where the scanner can discover vulnerabilities.

It can be costly and difficult to accurately test all complex workflows in today’s applications. NTOSpider gives you the ability to find vulnerabilities automatically, with more accuracy and in less time.

This new release of NTOSpider holds just one of many innovations that we are working on when it comes to automating web application security testing.

We understand how difficult and frustrating running a web application security testing program can be. Stay tuned! Our roadmap has many exciting advancements in store. We are committed to continued innovation and advancements that you won’t see anywhere else!

Information Security Podcast

An Information Security Place Podcast – 01-22-14

Jim, Dan, and Michael have a lot of catching up to do. We talk about a lot of stuff because a lot of stuff has been happening. From RSA, NSA, QSAs… security is busy! Show notes below!

Show Notes:

Infosec News Update

  • 123456 is the new best of the worst – Link
  • RSA Conf and those skipping it this year – Link
  • Fixing a flawed VA medical records system: Tenacity pays off for a researcher – Link
  • Do you believe the Obamacare website is secure? These guys don’t – Link1, Link2, Link3

Discussion Topic – The Failure Themes of the Target Breach

  • Massive Props to Brian Krebs on his coverage of the whole debacle –
  • AntiVirus Takes it on the Chin …Again – Link
  • Egress Filter Much? – Link
  • Credit Card Processing Fundamentally flawed – Link

EMPHATIC POINT OF THE PODCAST!! Complacent with Compliance … again PCI!= security

Music Notes

Special Thanks to the guys at RivetHead for use of their tracks“

  • Intro: “Stay Alive“ – Rivethead
  • Segment 1: “Synchroncity II“ – RivetHead
  • Segment 2: “Burn Us Down“ – Early Morning Rebel
  • Outro: “Zero Gravity“ – RivetHead

HO-FFL 2013 Wrap up


The season is over! It was fun to play with all that participated and I got to have some fun conversations about football & the week by week activity that took place. I am looking forward to our meetup at RSA. I am planning out a time & location and will have those details soon.

2013 Season Final Standings

  1. Billy’s Team – Billy Austin (@billyaustintx) from iScan Online
  2. False Positives – Chad Collins (@ChadCollins10) from uTest
  3. Hash Crackers – Lee Carsten (@lcarsten) & Patrick from the Denim Group
  4. Tomball Cowboys – Michael Farnum (@m1a1vet) from Accuvant
  5. Megatron - David French (@frenchdc) from Risk I/O
  6. boca steelers – Alan Shimel (@ashimmy) from The CISO Group along with his blogging & writing.
  7. Spicy Thai Peanuts – Brandon Spruth (@spicythaipeanut) from Morningstar
  8. brb…. Football 0x2 – Erin Jacobs aka “Security Barbie” (@SecBarbie) from Urbane Security
  9. Whamtastic - Joseph “Drew” Miller from Hewlett-Packard
  10. The Spearmint Rhinos – Gus Fritschie (@gfritschie) from SeNet International
  11. Mighty Hackers – Dan Kuykendall (@dan_kuykendall) from NT OBJECTives.
  12. Max’s Majestic Team – Max Dalziel @conciseonline) from Concise Online

Yes, you read that right… I ended up in 11th place. Ouch. In every other league I played in this year, I did pretty well, except this one. In this one, I stunk. Plain and simple…. just terrible. My one redemption was that I did have a chance to beat a couple buddies, David (twice), Brandon and Lee & Patrick. Downside was losing to Michael during the weekend after HouSecCon when I did my trash talking to him in person :/

Billy Austin just cleaned up. He had the most highest scoring weeks (5) and a couple second highest scoring weeks, which earned him $60, plus as league champ he earned another $60 for a $120 total plus all bragging rights.

I almost pulled Max’s team from him, because he left the team on auto-pilot and left bye-week players in his starting lineup a couple times. However, on week 8 with his QB on bye week, he still managed to get a win over Gus! Then on week 9 he left 2 bye week WR’s and a kicker on his starting lineup and still beat Drew!! He then got his 3rd and final win over ME in week 10 with no RB’s and no TE!!! (they were on bye or IR). Next season I will have a rule for this.

There was a big screw-up on my part that really limited the season for most of the teams. I did not setup the playoff schedule properly, so there was no consolation bracket, and so the top 8 teams entered playoff and seasons ended for everyone else. That was unintended and will be corrected for next season.

All in all, it was a fun experience and I look forward to next season. In the meantime I will be cheering on the 49ers as they make their way back to the Superbowl!!!


application authentication

If at first you don’t succeed, you’re hosed: The criticality of authentication in web scanning

We appreciate Kevin Beaver’s recent blog post about NTOSpider’s unique ability to authenticate on some of the trickiest applications and stay properly logged-in throughout the scan.

At NTO we take pride in helping our customers by solving the automation problems that limit most scanners. While, we strongly believe that there are things in applications that must be tested by human hands with human logic, the more that we can automate the better. Web applications continue to proliferate and become more complex. Even with comprehensive and advanced automation, there is too much for even the most sophisticated application security teams to do. I believe the vendor community’s responsibility is to continue to innovate against even the toughest application security scanning challenges.

application authentication

First of all, many thanks to Kevin for sharing his feedback on NTOSpider! It gives me a great opportunity to discuss the topic of automated logins. In a blog post earlier this year, “Web Application Security Scanning: The Art of Automation,” I enumerated several challenges in automated web application scanning, which included authentication, but here is a summary of some of the challenges when dealing with authentication:

  • Reliable automated detection of the login form. There are many possible formats, and they must be distinguished from other forms.

  • Automate the determination of a successful login vs. failed login (diff flavors of failures). This is one of the more challenging tasks that give web application security scanning vendors all sorts of headaches.

  • Deal with login forms that include onsubmit events that do crazy stuff such as client-side encryption of the password to “protect” it over the wire, or calculate some predetermined key based on some other token.

  • Handling Single-Sign On (SSO) solutions which require going to another domain/host for the login process.

    • Only send credentials to the intended SSO site

    • Properly handle the cookies from each domain, including those added by javascript routines

    • Must not attack the SSO site, but only use it for the login process.

  • Providing flexible backup solutions for instances where automation fails.

By creating technologies for the various problems, we make it possible for most scans to run successfully when just providing a URL and credentials. For example; for one of our customers has hundreds of complex applications, it simply is not possible to manually test each application. With one of their very large applications, they were challenged to reach the desired level of automation with their previous solution. It was very difficult to configure a scan which typically required weeks of trial and error to get the right configuration. Once the scanner was finally configured, the scan ran for more than a week and often crashed before it was complete. In many instances, the login training had to be re-done for each new scan. When the scan was performed by NTOSpider, it was able to automate the login and run to completion in a few days and with almost no training.

 One of the things that makes NTO different is our support. We understand that you are dealing with custom applications. You’ll often hear me say that every application is an edge case. These edge cases often require a customized solutions. When needed, we work directly with you to enhance NTOSpider to handle custom applications. The same customer I mentioned above had another application that had a form of two-factor authentication which asked the user to answer a revolving question, such as the color of your first car. Since the question would be randomly selected from five revolving possibilities, they needed a custom login macro. At the time, our existing login macro did not support such a situation. In response our support & development team took on the challenge and within a week we had extended our login macro solution to be able to figure out the question being asked and answer accordingly!

Another example of NT OBJECTives, innovating the art of automation!

New Technologies in WebApp Sec

Webcast: SQLInjection Vulnerabilities Hidden in New Places

Why are your applications still suffering from SQL Injection Vulnerabilities?

Even though we know so much about SQL Injection, we have a perfect storm brewing for serious security problems in many modern applications. The perfect storm is brewing because the younger generation of developers who are building these new applications in technologies like JSON, REST, SOAP and AJAX aren’t experienced in security and the security professionals who need to test them aren’t experienced in these formats.


To make matters worse, business managers are under pressure to get these applications out quickly which often results in inadequate security testing. And then we have the scanners. Most scanners were built to scan classic HTML based apps.

Please join me next week on Wednesday, October 16th as I share what I have learned after two years of testing “modern applications.” such as mobile, RIA’s and web services. I will demonstrate that they are susceptible to all the same SQL Injection mistakes of the past.

This webcast is designed for both developers and security professionals who want to learn more about how SQLInjection and other vulnerabilities hide in these modern formats. I will go through each format, review how to understand it and how to find vulnerabilities in it. Finally, I will discuss how to scale testing on these kinds of applications in an automated way.

Join me for this webcast to learn

  • Why SQL Injection is so prevalent in these technologies despite the fact that we have understood SQL Injection for so long.
  • How to understand these newer formats (JSON, REST, SOAP) and find SQL Injection vulnerabilities in nine technologies commonly used in these applications.
  • How you can scale your testing to automatically find these vulnerabilities.

Finally, we’ll discuss how you can scale your testing with automation to automatically find these vulnerabilities.

See more at:

The Seven Deadly Sins

7 Deadly Sins: Unlock the Gates of Mobile Hacking Heaven

The Seven Deadly SinsI’ve spent the past year hacking mobile applications in an effort to uncover the most common security mistakes made during development. I found that most of the problems are related to session management – the process of authenticating the user and ensuring an attacker isn’t impersonating a user or eavesdropping on the service. In most cases, a vulnerability in any single area isn’t a significant liability. However, the more mistakes that are made, the easier it is to attack the app. Here is what I consider to be the seven deadly sins of mobile application session management. How many are you committing?

1. Trusting the client

This is where it all begins. The primary sin is that developers inherently put too much blind trust into the mobile client app. The server should confirm the authenticity of every request from the application and treat every input as a possible attack payload. It is very similar to normal life, for example how often are you asked for your ID when using a credit card at a store? By failing to verify your identity the store is opening themselves and the credit card agencies to fraudulent purchases.

2. Not requiring encryption

Mobile devices use wireless communication, and it is easy for an attacker to peek in on that traffic. To limit what an attacker can easily see, it is necessary to encrypt the communication with SSL. In too many cases I see mobile apps failing to use SSL, or when they do use SSL, they fail to require valid certificates making it useless for securing communication.

Developers also leave users clueless about the use of encryption by their mobile apps so they have no idea if their information is being broadcast to anyone who cares to loo

3. Allowing lifetime sessions

Mobile application sessions often last for a very long time because mobile users hate to login again. The session for some apps might be valid for months or even years. As long as they can keep the session alive, attackers can make malicious requests, effectively impersonating users. Additionally when a phone is lost, these apps have active sessions open.

It is simply a bad idea to trade away all security in favor of a minor inconvenience to users.

4. Not keeping secrets

Once a mobile app authenticates with a server, it is given a session token that is used for identification from then on. This session token is sent with every request to the server, and can often be seen and stolen by attackers. To improve security, developers need to keep a secret token on the mobile client that can be used to perform extra security checks. This is like a secret encoder ring. The client can use the secret encoder ring to “sign” all of its requests. Since the secret encoder ring is not sent with each request, it cannot be easily stolen and is a great way to confirm the validity of each request.

 5. Not limiting the amount of time a request is valid

Mobile apps make requests to send data or get data. These requests need to be time stamped to limit how long they are valid. The longer a request is valid, the more time an attacker has to work with. Sometimes these requests are not sent immediately (for example, when the connection is interrupted, as when the user is going down the elevator, in a parking garage, etc.). Thus, developers allow requests some time to be received by the server. However, the business must define a limit that makes sense. This limit is defined on the server side, and the requests need to be time-stamped on the client side. Once the time limit is past, the request becomes invalid and the client has to create a fresh one if needed.

6. Allowing repeat requests

When attackers intercept communication from a mobile device, they have several options depending on their motivation and desired impact, but one option is to simply replay those requests as is. If the request is to send a Tweet, maybe it has little impact besides being annoying. However, if the request is to transfer money and that request gets sent over and over again, this can have real monetary impact. This can be prevented by using a NONCE (number used once) on every request.

Here’s how the NONCE works: The client generates a random number – the NONCE – for each request made. The server keeps a list of the used NONCE’s, and once a number has been used before, the server knows that future requests with the same NONCE are invalid.

This should be combined with advice from sin no. 5. A time limit helps restrict the list of NONCE’s that must be stored by the server.

7. Failing to prevent altered requests

In the discussion of sin No. 6, repeat requests, we mentioned that once an attacker intercepts a request they have some choices. Instead of simply replaying the request, they may want to alter it; for example, change the account the money is transferred to. This can be prevented by “signing“ each request using cryptographic methods.

The developer can use a shared secret or a cryptographic key pair to ensure that requests are not modified. Simply creating a HMAC of the content being sent and including this with the request allows the server to confirm that the content was not altered.

So you can use the key to sign the data. For example, I’m going to send “this is a test.” I would “hash” it with my secret key, “#t@h15isat3st,nonce value,timestamp (hashed all together) (so there is no way to manipulate the nonce) they would see that secret key and they would know that only someone with that secret key would know that it’s a match. Now, that it’s easy for the server to verify that it’s valid content, they can be confident that it’s from the authenticated user.


It is important to apply all these techniques together for the most secure solution. If developers consider every request as a possible attack (no. 1) or a possible leak of information to the attacker (no. 2) then they will also want to limit the time they give the bad guys (no. 3). The developer can use the secret key (no. 4) to sign the content (no. 7), including the time stamp (no. 5) and the NONCE (no. 6) to ensure that none of the three data points are altered.

By using all of these solutions in combination, it is possible to provide a secure solution when building mobile apps.


HO-FFL Update

We are now in the middle of week 4, but I want to catch everyone up on whats been happening. HO-FFL-Logo

First of all, I am currently ranked 10th in our 12 team league. Wow, that’s embarrassing! Fortunately for me its early in the season and I am going to win my matchup this week, which will jump me up in the rankings a bit.

Week 1) I got off to a good start as I crushed my opponent @frenchdc and expected the trend to continue. However the best team in week 1 was @billyaustintx who was our first top scoring team and earned the first $10 prize.

Week 2) This week I faced Chad @ChadCollins10 and expected an easy win which I was projected to get. However as it goes with fantasy football, you never know… Chad had Julio Jones who had a monster game, and I had 3 players from the 49ers who bombed out. Between Kaepernick, Anquan Boldin and Vernon Davis I got 13.75 (big ouch) and Chad nearly doubled my score. This week’s top scoring team was Spicy Thai Peanuts (@spicythaipeanut) as he beat the Has Crackers,

Week 3) Once again I go down to defeat because of the 49ers imploding. I sadly lost by a mere 3 points  to @SecBarbie. We both had a bad week, but mine was just slightly worse. At this point I have now dropped to 10th place. Our top scoring team of the week is Drew’s Whamtastic. Congrats One other interesting fact at this point is that @ChadCollins10 team False Positives is the top ranked team, yet has not won any money yet from being the top or 2nd best point earner for the week. I guess he is playing the slow steady game to make sure he wins the league trophy prize.

Week 4) We are now in the middle of week 4, and we have one game left for Monday Night Football. From the looks of it, I should win my week and can at least move up to the middle of the pack. I have alot of work to do to make sure I make it to the playoffs and then have structured a winning team this season!

Good luck everyone. I’m having fun and I hope those that are playing it are having fun, as well as those watching the league.


Yahoo Fantasy Football

Mobile Application Security: Think Twice Before Placing Football Bets

Have you heard about the vulnerability in the Yahoo! Fantasy Football app? If Knowshon Moreno’s performance on Monday against the Oakland Raiders got you down, you might want to read this warning to fantasy football players: Don’t place any bets this season until you update your Yahoo! Fantasy Football mobile app. A hacker could be manipulating your lineups, putting injured or poor performing players in the weekly lineup while benching top-seeded players on your team – essentially stacking the odds against you.

Oakland Raiders v Denver Broncos

During vulnerability testing we found that a previous version of the Yahoo! Fantasy Football mobile app is vulnerable to session hijacking (video) – the process of authenticating the user and ensuring an attacker isn’t impersonating a user or eavesdropping on a service. The vulnerability allows an attacker to impersonate another player on message boards and manipulate other players’ lineups.

We acknowledge that at least in this case the vulnerability is relatively benign, you can lose your bet of course, but its not the end of the world. However, it is indicative of a larger problem: the general lack of attention paid to security during development and testing. Some of the most common security mistakes made during mobile web app development are related to session management. In most cases, a single vulnerability isn’t a significant liability, but the more mistakes developers make, the easier it is to attack the app. This is the case with Yahoo’s fantasy football application.

It is also concerning that the application went public without proper security testing – which would have uncovered the vulnerability. Oftentimes organizations are in a hurry to deliver mobile apps and sacrifice security as a result.

Finally, as a user of mobile apps, it is worth noting that failing to update your mobile apps in a timely manner puts you at unnecessary risk when vulnerabilities have been fixed in later versions.


Four Reasons Security Teams Can’t Stop SQL Injection Vulnerabilities

SQL injection vulnerabilities have threatened application security for years. So why are they still quite common, despite the fact that we, as an industry, should know how to prevent them? Clearly, if eradicating the vulnerability was contingent on understanding how to implement a technical fix, we would’ve done so by now. But the problem is much bigger than that, and it requires a deeper look into web application security testing as a whole. Below, we’ve listed some of the factors that come into play from the security team’s point of view.


  • A lack of resources: Security organizations run lean and mean these days. They simply don’t have the staff, time or technology to dedicate to fixing every vulnerability. Plus, when resources are tight, it can be tempting to take shortcuts, which can easily decrease the level of application security altogether.

  • Not enough time in the day: Security teams are in a race against hackers to find SQL injection vulnerabilities, prioritize them according to severity and remediate them – not for just one, but for hundreds of applications.

  • Humans are fallible: Pen testers are the experts at finding SQL injection vulnerabilities, and they must employ a combination of automated and manual tests. Using one at the expense of the other or using rudimentary technology can leave some vulnerabilities undetected.

  • Lack of control: Because security teams have little control over developers, they often have little influence over development training, policies and coding practices.

It’s evident that security teams have their work cut out for them when it comes to providing effective application security against SQL injection vulnerabilities. Fortunately, they don’t have to face the challenge alone. Together, security specialists and developers should work as a team to prevent future vulnerabilities and eradicate any current ones. Unfortunately, developers do face a host of challenges of their own.