Man Vs WebApphttp://www.manvswebapp.com
Web Application Security Blog and PodcastFri, 29 May 2015 21:01:42 +0000en-UShourly1http://wordpress.org/?v=4.02006-2012 mightyseek@gmail.com (Dan Kuykendall)mightyseek@gmail.com (Dan Kuykendall)1440http://www.manvswebapp.com/images/itunescover144.jpgMan Vs WebApphttp://www.manvswebapp.com
144144http://www.manvswebapp.com/feed/podcastA podcast dedicated to Web Application SecurityA podcast about web application security, as well as general web application development issues. The primary focus is on security with an effort to explain things so that anyone can understand them since security issues affect everyone across an organization. Hopefully this show will be a resource for everyone involved in a software development project.Dan KuykendallDan Kuykendallmightyseek@gmail.comnonoShellshock Bash Bug – 8 Important Lessonshttp://www.manvswebapp.com/8-important-lessons-we-can-learn-from-the-shellshock-bash-bug
http://www.manvswebapp.com/8-important-lessons-we-can-learn-from-the-shellshock-bash-bug#commentsFri, 03 Oct 2014 22:16:45 +0000http://www.manvswebapp.com/?p=2785While Shellshock has been all over Twitter and talked about on prominent news outlets, I’m still shocked that there is comparatively less press coverage than there was for Heartbleed which was a bonafide “big story.” This is unfortunate because in some ways the Shellshock exploit is more devastating, but there are actually some good reasons for the lesser coverage, and all of them are things we should learn from.

1. Name Game ConfusionSome call it Shellshock, or the Shellshock Bug, some call it the “BASH Bug” and sadly, some in the press call it the “Bug known as BASH” (see video [https://www.youtube.com/watch?v=hxsb8Hzb5FQ]). Heartbleed was a cool name, and even had a cool logo that was able to capture the imagination very quickly. Maybe we need to make sure we pick cool names and create cool logos before we alert the media of a major new vulnerability.

2. Explanation of the ThreatWhen dealing with Heartbleed it was easy to explain that the exploit allowed an attacker to extract unencrypted information. With Shellshock, I have seen people trying to explain the exploit in terms that are meaningless to normal people.

3. The Boy Who Cried WolfWe (the security community) made such fuss about Heartbleed and we basically told the world that the internet was on fire. The problem was that most of the internet was patched within a week or two and life went on as normal. The fire was well contained by the awareness campaign which is a good thing. But we had gone a little overboard and wasted our goodwill with the press.

4. Overstatement of the ThreatLet me start by saying, that when exploited, Shellshock is bad bad news. A Shellshock exploit is worse than a Heartbleed exploit because it’s not only allowing data to be leaked, but also allows remote control of a server and could allow an attacker to make a trusted site become evil.

I see statements out there saying that 70% or even 90% of internet connected systems are vulnerable to Shellshock and that it is much worse than Heartbleed. While there may be some truth to that, and a high percentage of internet servers are indeed “vulnerable” we need to break that down a little because a very small percentage are exploitable.

5. Vulnerable Does Not Mean ExploitableA server might have this BASH bug which can be tested on the system with a simple test command. However, to exploit this, you need to have a service open that calls BASH. The problem is that most service ports are blocked by firewalls. In most cases, there are only a few ports open to the internet that could be vulnerable, such as DNS, DHCP, SMTP/IMAP/POP3 and HTTP/HTTPS. I have seen some exploitable examples of DNS and DHCP services that shell out to BASH scripts to handle IP assignments based on user, as well as some SMTP that shell out to SPAM filtering tools. I’m sure there are many more, but these are examples and they are limited. Jose Pagliery from CNN Money explains it quite well – the world isn’t on fire, but there is a serious problem in this video.

6. What About Web Servers?Of course this is one of the big questions because web servers are much more widely exposed to the ShellshockBASH bug. In many cases, the only ports a server will expose to the internet are 80/443 which are the HTTP/HTTPS ports. There are situations where a web server has CGI support enabled, even though it has not been the default configuration for quite some time. But if it is, then it is possible that it might have a CGI script that executes BASH. This could happen, but it’s fairly rare these days because most CGI scripts I see are written in languages such as PERL and are not exploitable with ShellShock. So, if all the moons have aligned so far and there is a BASH CGI script in use, the admins can disable the script or patch the system to remove the vulnerability.

So lets go back to the claims that 70-90% of the internet connected servers are “vulnerable”. From that we subtract the ones that have no ports open to the internet. We then remove the ones that only expose services that are not exploitable because they don’t shell out for any reason. In the end, I think we end up with a much smaller percentage, lets say 5%-10% of the servers on the internet that are vulnerable to the Bash Bug are actually exploitable.

7. Remains A Very Serious Security IssueEven if only 5% of the servers on the internet are exploitable that still constitutes a very serious problem. It may not get as many headlines as saying 70-90% are vulnerable, but it is more accurate and helps to maintain our credibility to the wider public.

Keep in mind, that 5% of the servers on the internet being exploitable is still a VERY LARGE number of servers, and from those exploitable systems, an attacker could then attack other servers and services not exposed directly to the internet.

8. Shellshock’s Lasting ImpactI want to state once again that I strongly feel like this BASH bug is very serious, which is why I have been disappointed by the coverage about it. I also think it will be with us for a long time, because unlike the big servers powering the internet, which will get patched, many appliance type devices will never get patched such as common home WiFi & router devices, and IP enabled devices that fall into the “Internet of Things” category.

We did a great job during Heartbleed, and I believe the publicity actually helped mitigate the threat because every IT person was made aware and systems were patched quickly. It also served as something like a shark alert at the beach and many people stayed away for a few days while “the internet got fixed.”

Shellshock has not been handled as well, and I think systems that could easily be patched won’t, because we failed in the awareness campaign. I have run into many people and friends in the IT space that had not heard about it as recently as last night!

I hope we do better next time.

]]>http://www.manvswebapp.com/8-important-lessons-we-can-learn-from-the-shellshock-bash-bug/feed0The Bash Bug, In a Nut-Shellshockhttp://www.manvswebapp.com/bash-bug-nut-shellshock
http://www.manvswebapp.com/bash-bug-nut-shellshock#commentsFri, 26 Sep 2014 20:35:48 +0000http://www.manvswebapp.com/?p=2773As you probably know by now, a bug, named Shellshock or “The Bash Bug” has been discovered in a version of Bash, which is a command shell tool. The bug leaves millions of websites and computers open to attack. The bug can be executed in just a few lines of code and enables Hackers to use the command shell remotely to execute malicious injections without admin privileges into vulnerable sites, possibly bringing them down or worse.

Some say the damage potential for this bug is so massive, it’s being compared to Heartbleed – and, it may even be more pervasive than Heartbleed. But, others say that its been around for a long time and the damage will be minimal. Security insiders are tweeting all sorts of sarcastic comments and jokes about the bug while some publications warn of gloom and doom. While the damage will remain to be seen, it’s fairly safe to say that this bug is keeping security professionals and developers busy.

Technically, no one is safe from Shellshock, it exposes everyone from home users to global corporations. Both Rapid7 and NIST vulnerability database score this vuln a 10 out of 10 and unfortunately its pretty easy to execute. Experts are urging IT professionals to patch their version of Bash ASAP, but keep in mind that there isn’t one solution. IT security experts and developers will need to issue patches for their individual solutions (ex. Apple, RedHat, etc.). For example:

Linux vendor RedHat has issued ModSecuritiy rules that block the Bash bug, but warns that the patch is not complete.

Security researchers are worried about the bu’s potential impact on Apple Mac computers, which uses the Bash software which the bug exploits directly in the form of its command-line program Terminal. Fortunately, patches are available, but Apple users will need to get their hands dirty until a fix is issued.

Shellshock is a mistake in the code of Bash, which is typically installed on non-Windows operating systems such as Mac, Unix and Linux. The bug enables hackers to send commands to a computer remotely and without having admin privileges. The recent vulnerability was discovered by Akamai security researcher, Stephane Chazelas. This Akamai advisory also explains the problem and this OSS-Sec mailing list post has a good explanation as well..

IT security professionals can find code to exploit the Bash bug using CGI scripts to execute code with the same privileges as the web server. The bug can be triggered on a vulnerable system with a simple Wget fetch.

To check if you’re systems are vulnerable, execute the following lines of code in your default shell, which will often be Bash.

You’ll know you are at risk if you see the word, “busted.” If you don’t see the word “busted,” then your version of Bash is fixed or your shell is using a different interpreter.

Users at home should avoid using credit cards or disclosing personal information on-line for the next few days. In addition, its a good idea to update anti-virus software and avoid sketchy websites.

In Jim Reavis’ Cloud Security Alliance blog post, he explains that many large programs on Linux and other UNIX systems use Bash to define environmental variables which are then used while executing other programs.

For more helpful information on the Shellshock bug, check out the following:

]]>http://www.manvswebapp.com/bash-bug-nut-shellshock/feed0Why the Bitcoin Intrinsic Value Complaint is Irrelevanthttp://www.manvswebapp.com/bitcoin-intrinsic-value-complaint-irrelevant
http://www.manvswebapp.com/bitcoin-intrinsic-value-complaint-irrelevant#commentsTue, 04 Mar 2014 18:58:22 +0000http://www.manvswebapp.com/?p=2642In the aftermath of the Mt. Gox meltdown and subsequent bankruptcy filing, I have been reading a lot of commentary on Bitcoin. Even Paul Krugman has weighed in (against Bitcoin). Much of the criticism of Bitcoin centers around the idea that it has no ‘Intrinsic Value.’ While I have no particular opinion on whether or not Bitcoin is over or undervalued or whether it has long term viability, the Intrinsic Value criticisms are unfounded and based on a misunderstanding of Intrinsic Value, value and currency mechanisms.

A quick review of economic and financial principles will reveal that Bitcoin could have Intrinsic Value and be sustainable despite the fact that it is not backed by gold or a government’s power to tax.

What is Intrinsic Value?

Intrinsic Value is a concept in finance that attempts to value an asset (usually a financial asset like a stock or bond) based on a mathematical analysis of the (usually cash) value derived from that asset over time. Usually, discounted cash flows are used. So, for example, if a company is expected to pay dividends of $1 per year forever and an investor applies a discount rate of 10% to those dividends, the stock will be worth $10 per share ($1/.1).

This approach can be applied to assets that do not throw off streams of cash. For example, if I own a right to have dinner for two at a restaurant once a year and I value that at $100 with a discount rate of 10%, that right is worth $1,000 ($100/.1).

It should be pointed out that many assets with Intrinsic Value are not entirely backed by another asset (like gold) and the vast majority are not backed by a government’s right to use force to collect taxes.

As we will see in a bit, using the standard definition of Intrinsic Value, Bitcoin may very well have Intrinsic Value even though it is not backed by something with established value (e.g. gold) or a government’s right of taxation. All that is necessary to use Intrinsic Value analysis is for the asset in question to have tangible benefits that accrue to the owner over time.

Are All Values Intrinsic?

Most items with monetary value do not have Intrinsic Value. In other words, they do not throw off cash flow or other measurable benefits over time. For an item to have monetary value it needs to have two things and two things only: scarcity and demand. That’s it. Economics is about understanding human behavior, not judgement. If a lot of people want a baseball card and are willing to pay $80,000 for it, it’s worth $80,000. Period, end of story. If people are willing to pay $1,000 for an ounce of gold, that is what it is worth.

It should be pointed out that gold is not valued by Intrinsic Value analysis. It’s good old (scarce) supply and demand, econ 101, day 1. Gold certainly has a more established value based on a long history of it being a store of value but that’s it.

Why Are Currencies Useful?

Switching gears a bit, let’s talk about currencies. There are two potential uses of currencies. They can be used 1) as a store of value and 2) as a medium of exchange. The store of value is obviously needed for it to be a useful medium of exchange over the short term because if you have $3,000 in your checking account that you need to pay the rent, you need to know that it will be worth roughly that when the rent comes due next week.

Having said that, currency values change daily in relation to each other and over longer periods in their own country. If the federal reserve doubles the money supply, it will cause inflation and my rent will go up as the US dollar will be worth less to my landlord (it will buy less).

The point of all of this is that just because Bitcoin’s value has been and will continue to be volatile, that does not mean that it has no use as a medium of exchange.

Taking another step, there are many factors that impact the utility of a currency as a medium of exchange. Let’s look at three of them.

Acceptance. Clearly if no one will accept a currency as payment, it is useless as a medium of exchange. The more entities that accept it, the more useful and valuable it is.

Transaction Costs. The less that it costs the buyer and seller to transact in a currency, the more useful it is. This is a major consideration and US dollar transaction costs can be significant. Credit card companies charge 2.5% or more to process a transaction.

Anonymity. For certain sectors of society, anonymity is highly valuable. Some people simply do not want their transactions traceable. Some of this demand may come from mere paranoia and certainly a significant portion of it relates to criminal activity.

Is Bitcoin Potentially Useful?

The answer, quite clearly, based on 1, 2 and 3 above is yes. While Bitcoin does not have the broad acceptance of the US Dollar at present, broad acceptance is not a requirement for it to have value. All that is required is for a meaningful subset of users to see value in using the currency for them to use it. Clearly transaction costs are lower and Bitcoin’s anonymity is very attractive.

Could Bitcoin Have Intrinsic Value?

The answer, according to finance theory, is a clear yes. Let’s recall that Intrinsic Value has nothing to do with something being backed by gold or the power of taxation. Again, all that is necessary to use Intrinsic Value analysis is for the asset in question to have tangible benefits that accrue to the owner over time.

Just looking at the transaction costs, we can measure the value of Bitcoin as the sum of the net present value of money saved over time by using it as compared to currencies with higher associated transaction costs. To create a simplistic example, let’s say that I keep a $3,000 worth of Bitcoins to use for a certain number of transactions per year. Think of it like a checking account. Let’s say that I do $15,000 worth of transactions a year and save 2%, on average, on each transaction for a total of $300 per year. Assuming a discount rate of 10%, the Bitcoins are worth $3,000 to me ($300/.1). It is actually quite possible to save 2% per year or more and $15,000 of annual transactions on a $3,000 account is very do-able as well.

The fact that the Bitcoins are not backed by gold or the power to tax is no more relevant to me than the fact that I have my retirement savings invested in General Electric Stock (which is neither backed by gold nor the power to tax). The Bitcoins have $3,000 worth of value (Intrinsic Value) because they deliver $300 per year of tangible benefits to me as an owner. If had a magic wand or totem that saved me $300 per year on transaction costs, that would be worth $3,000 to me as well using the same analysis.

The benefits for criminal activity are even greater as money launderers charge substantially more than 2% (at least according to my favorite television shows). And the IMF estimates that 2-5% of global economic activity involves money laundering ($1.4 – $3.5 trillion per year). Bitcoin is not a complete solution for criminals as it does not yield a stable asset post-transaction but criminals may be willing to take some Bitcoin volatility risk for a portion of their portfolios in order to save on transaction costs.

Now I may have some value risk or piracy risk on my Bitcoins but that is something that I may be willing to take to save money on transaction costs and/or to achieve anonymity.

Conclusion

I’ve never used Bitcoin and have no plans to do so. Having said that, as a business owner, I am well aware that transaction costs are material and a new transaction mechanism (that may or may not include a new currency) could have value and gain adoption. Bitcoin, or other digital currency like it, could certainly be that mechanism. Whether it will succeed or not, I have no idea. But focusing on a misunderstanding of both Intrinsic Value and why currencies are useful will certainly not shed any light on the subject.

]]>http://www.manvswebapp.com/bitcoin-intrinsic-value-complaint-irrelevant/feed0An Information Security Place Podcast – 01-22-14http://www.manvswebapp.com/information-security-place-podcast-01-22-14
http://www.manvswebapp.com/information-security-place-podcast-01-22-14#commentsThu, 23 Jan 2014 03:37:40 +0000http://www.manvswebapp.com/?p=2629Jim, 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!

]]>http://www.manvswebapp.com/information-security-place-podcast-01-22-14/feed00:33:53Jim, 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[...]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 – Krebsonsecurity.com
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“ http://www.rivetheadonline.com/
Intro: “Stay Alive“ – Rivethead
Segment 1: “Synchroncity II“ – RivetHead
Segment 2: “Burn Us Down“ – Early Morning Rebel
Outro: “Zero Gravity“ – RivetHead
Mobile, Network, Physical, SecurityDan KuykendallnonoAn Open Letter to Barack Obama: If You aren’t Sure of Health Exchange Security, Shut it Down Nowhttp://www.manvswebapp.com/open-letter-barack-obama-arent-sure-health-exchange-security-shut-now
http://www.manvswebapp.com/open-letter-barack-obama-arent-sure-health-exchange-security-shut-now#commentsFri, 25 Oct 2013 14:37:47 +0000http://www.manvswebapp.com/?p=2605Stability in Only the First Issue – Security Will Be Healthcare.gov’s Real Achilles HeelThere has been a significant amount of attention to the the problems of the Obamacare website. While these problems are certainly cause for concern, there are an even more serious group of problems that likely exist and need to be addressed. These have to do with the security of the website and the confidential data that it is collecting on millions of Americans. Given the problems with the site that have already been discovered, if concerns about security cannot be addressed, the site should be shut down until they can be. Slow performance is an inconvenience. The dissemination of confidential information on millions of Americans would be a disaster. Given that a casual test of the home page of the site revealed a security flaw, we are gravely concerned about the security of the site as a whole.

We would emphasize that this is not a hypothetical problem; confidential data is stolen every day by hackers who exploit the security flaws discussed below. If the designers of healthcare.gov have not addressed these issues, the site is vulnerable to user data being stolen and it is almost certain that hackers will exploit this. Unless the Administration is certain that the site can securely protect the confidential user data it is collecting, the site should be shut until that it has that degree of confidence.

The Obamacare Website is a Prime Target for HackersIt’s obvious this site is a target for hackers. First and foremost, it is set up to collect and aggregate personal, confidential information on millions of Americans. Second, the US government always has enemies and embarrassing the administration would appeal to a large segment of the hacker community. Given the current NSA scandal, anti-American sentiment in the hacker community might be at its all time high. Finally, many hackers are motivated by augmenting their reputation among other hackers. Hacking healthcare.gov would certainly be a prestigious hack.

The Security Flaws in the Site Are Still Largely UnknownHacking requires the ability to make thousands of clicks on a site to test for flaws. A single page may require a thousand tests to ensure that it is secure. Healthcare.gov has such poor stability, this is nearly impossible. Once the stability of the site improves, hackers will test it thoroughly. At this point, the true security profile of the site will be made clear.

Healthcare.gov Likely Has Significant FlawsGiven the multitude of problems with the site, it is clear quality testing was lax. It is generally true that functionality testing (i.e. does the site actually work) is is prioritized over security testing. It is likely that the site’s security is even worse than its functionality. We very lightly and casually poked around the first page of the website and found a significant vulnerability that is easy to discover and prevent. It is highly unlikely that this is the only vulnerability on the site. We would also point out that fixing problems on the fly under intense pressure is not an intelligent way to fix enterprise software. Human beings are responsible for preventing security flaws and these are exactly the kind of conditions that lead to security mistakes.

How Website Vulnerabilities Allow Hackers to Steal Confidential User DataThere are two main classes of vulnerabilities that are most concerning. The first of these are called SQL Injection. Web Applications, by design, connect to databases and the databases, by default, give the applications any data that they request. If the applications are not secure, hackers can inject commands to steal or alter all of the data in the database. These vulnerabilities are relatively easy to find and correct. Of course so was the vulnerability we found on the home page, so there is no guarantee that healthcare.gov is free of SQL Injection.

The second class of vulnerabilities of significant concern covers who gets to see what information. There are different types of users of an application and generally, there is a class of user, called an admin or administrator, who has broad access to data. This is necessary because administrators are often called upon to fix problems with the site. Applications control who gets to see what by a variety of means. It is very possible to fool the site into thinking that a non-admin user is an admin, giving a hacker broad access to user data. It is very difficult, expensive and time consuming to test for this class of vulnerability.

Regulatory ComplianceIt’s interesting that many private organizations are required to adhere to certain regulatory guidelines like PCI, HIPAA and FISMA, but this application seems to escape them. While this application may not fall under HIPAA guidelines, it does store important personal information like social security numbers. If it was subject to HIPAA (according to this blog by Erik Kangas which simplifies the requirements), it would have failed at least two of the requirements. Based on the security vulnerabilities being discovered and reported it would fail #4 which requires integrity of the data. Requirement #6 states that data can be deleted when needed. From the reports and legal notices we are seeing, it appears that there is NO WAY to delete your data once you provide it.

We just used HIPAA as an example. We could find several failed requirements against PCI as well. So, why is it that a government application that stores social security numbers isn’t subject to regulatory compliance regarding security?

Given The Risk of a Catastrophic Hack, Shut it Down!We have no information on what kind of security testing has been done on healthcare.gov. But the factors listed above, along with our security tests, give us significant cause for concern. We believe the Obama Administration should be up front with the public as to what security testing was done, by whom and what the results were. If there is not a very high degree of confidence that healthcare.gov is securely protecting the confidential data entrusted to it by the American people, it needs to be shut down until it can be repaired.

]]>http://www.manvswebapp.com/open-letter-barack-obama-arent-sure-health-exchange-security-shut-now/feed0HO-FFL Updatehttp://www.manvswebapp.com/ho-ffl-update
http://www.manvswebapp.com/ho-ffl-update#commentsMon, 30 Sep 2013 07:57:25 +0000http://www.manvswebapp.com/?p=2520We are now in the middle of week 4, but I want to catch everyone up on whats been happening.

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.

]]>http://www.manvswebapp.com/ho-ffl-update/feed0Four Reasons Security Teams Can’t Stop SQL Injection Vulnerabilitieshttp://www.manvswebapp.com/reasons-security-teams-stop-sql-injection-vulnerabilities
http://www.manvswebapp.com/reasons-security-teams-stop-sql-injection-vulnerabilities#commentsFri, 13 Sep 2013 19:09:13 +0000http://www.manvswebapp.com/?p=2450SQL 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.

]]>http://www.manvswebapp.com/reasons-security-teams-stop-sql-injection-vulnerabilities/feed1Eight Reasons Why SQL Injection Vulnerabilities Still Exist: A Developer’s Perspectivehttp://www.manvswebapp.com/reasons-sql-injection-vulnerabilities-exist-developers-perspective
http://www.manvswebapp.com/reasons-sql-injection-vulnerabilities-exist-developers-perspective#commentsFri, 13 Sep 2013 15:04:36 +0000http://www.manvswebapp.com/?p=2447Knowing how to prevent a SQL injection vulnerability is only half the web application security battle. A multitude of factors come into play when it comes to writing secure code, many of which are out of the developers’ direct control. That’s why common vulnerabilities like SQL injection continue to plague today’s applications, and why application security testing software is so important. These problems can be overcome – with a little insight, organizations can begin to address these challenges directly and better enable developers to remediate SQL injection. Here are the top eight reasons SQL injection vulnerabilities are still rampant:

SQL itself is vulnerable. SQL is designed to allow people access to information and is therefore inherently vulnerable, so every developer must know how to prevent SQL injection – not just one or two individuals on your development team.

The price of agnosticism. SQL is agnostic, meaning it works across database platforms. The upside to this is that it allows code to be database-server agnostic. But it is also the source of the problem. To prevent most vulnerabilities, developers should use parameterized SQL or stored procedures specific to the database server.

One mistake is all it takes. If just one vulnerability is left unsecured, a hacker can have his way. Every single input must be protected. Unfortunately, this is a tall order for any development team, as there can be tens of thousands of potential vulnerabilities on a single website.

Inexperienced developers lack training on old vulnerabilities. New generations of developers do not always receive the training and mentoring necessary to understand how to prevent common application vulnerabilities. They must be taught how to prevent exposing SQL injection vulnerabilities by creating comprehensive validation logic on every parameter or input.

Seasoned developers lack training on new technologies. Many veteran developers are using new formats and technologies to develop new types of applications. They must understand that SQL injection should still be considered for every input. For example, the application inputs from a mobile interface written in JSON that access the backend database can be as vulnerable to SQL injection as any input on an end-user page.

It’s not a priority. Many organizations do not consider fixing web application security vulnerabilities to be as important as they should. As a result, developers are generally more concerned with building new features and fixing bugs that impact user functionality.

It requires team effort. In order to eradicate SQL injection vulnerabilities, development and web application security teams must collaborate. Developers need security specialists to keep them informed of new hacking techniques, and security teams need developers to eliminate vulnerabilities.

Abandoned legacy applications. With the original application developers retired and the source code difficult to locate, vulnerabilities in legacy applications can be difficult or impossible to patch.

As you can see, educating developers on how to prevent SQL injection vulnerabilities won’t completely solve the problem. Organizations must enable developers to build secure code and make web application security testing a priority. Security teams have their perspective as well. Check out this blog to see the Four Reasons Security Teams Can’t Stop SQLInjection.

]]>http://www.manvswebapp.com/reasons-sql-injection-vulnerabilities-exist-developers-perspective/feed0An Information Security Place Podcast – 8-20-13http://www.manvswebapp.com/information-security-place-podcast-8-20-13
http://www.manvswebapp.com/information-security-place-podcast-8-20-13#commentsWed, 21 Aug 2013 06:35:28 +0000http://www.manvswebapp.com/?p=2404The podcasting returns! This is the first new episode of InfoSec Place and in a few days will be the return of my web security podcast here on Man Vs Webapp (formerly Mightyseek).

]]>http://www.manvswebapp.com/information-security-place-podcast-8-20-13/feed00:33:39The podcasting returns! This is the first new episode of InfoSec Place and in a few days will be the return of my web security podcast here on Man Vs Webapp (formerly Mightyseek).
Show Notes:
InfoSec News Update
Scan the Entire Internet in less tha[...]The podcasting returns! This is the first new episode of InfoSec Place and in a few days will be the return of my web security podcast here on Man Vs Webapp (formerly Mightyseek).
Show Notes:
InfoSec News Update
Scan the Entire Internet in less than 45 minutes!! – Article Link and tool link
Zuckerberg’s Profile Hacked – Link and Fundme campaign launched by my buddy Marc Maiffret from Beyond Trust
FDA Issues Guidelines on Wireless Medical Devices – Link
OWASP Top 10 Update – Link
Malware Sandboxing Not Working – Link
Sparty: MS Sharepoint and Frontpage Audit Tool – Link
HouSecCon Update! – Link
Discussion Topic
The Threat of Social Engineering – Jigsaw FTW
Link 1
Link 2
Music Notes: Special Thanks to the guys at RivetHead for use of their tracks – http://www.rivetheadonline.com/
Intro – Stay Alive – Rivethead
Segment 1 – – RivetHead
Segment 2 – – RivetHead
Outro – Zero Gravity – RivetHead
MiscDan KuykendallnonoHacking Fantasy – Hackers Only Fantasy Football Leaguehttp://www.manvswebapp.com/hackers-only-fantasy-football-league
http://www.manvswebapp.com/hackers-only-fantasy-football-league#commentsTue, 20 Aug 2013 01:05:49 +0000http://www.manvswebapp.com/?p=2361This November I will be presenting at AppSec USA, Revenge of the Geeks: Hacking Fantasy Football Sports Sites. While I enjoy hacking fantasy football apps, I also enjoy playing the game. So this year, I am starting a hackers only fantasy football league. Come join us to have fun and maybe make a little money!