Beating Web Application Security Threats

BEATING WEB APPLICATION SECURITY THREATS
The rapid increase in usage, development and complexity of Web applications has created new opportunities for companies that employ them and hackers who attack them. This handbook delivers up-to-date information on security threats to Web 2.0 and rich Internet applications and expert advise on how to avoid those threats. BY KEVIN BEAVER
CHAPTER 1:
CHAPTER 2:
CHAPTER 3:
CHAPTER 4:
CHAPTER 5:
New Web application security challenges
Assessing your Web application security
Beating common Web security attacks
Hacking your own applications
Overview of best practice tips and checklists
CHAPTER 1: NEW WEB APPLICATION SECURITY CHALLENGES
Introduction: New Web application security challenges
CHAPTER 2: ASSESSING YOUR WEB APPLICATION SECURITY
CHAPTER 3: BEATING COMMON WEB SECURITY ATTACKS
CHAPTER 4: HACKING YOUR OWN APPLICATIONS
CHAPTER 5: OVERVIEW OF BEST PRACTICE TIPS AND CHECKLISTS
time to be a software professional. Whether you develop code or try to break it, weve never had such great opportunities to work with so many dynamic technologies. From in-house development of Web 2.0 applications using ASP.NET to ISVs developing the next big thing for the cloud using Java, weve advanced quite a bit from the more simplistic days of BASIC, FORTRAN, and COBOL. With this advancement comes complexity though. And, as were finding out, complexity is the enemy of security. There are numerous aspects of complexity in todays software development lifecycles beyond the codebase itself as shown in Figure 1 (page 3)all of which create unique application security challenges. Its easy to get so caught up in work that we fail to see these things as creating barriers to the software development lifecycle, and ultimately, security. Let me elaborate on each item.
TS A GREAT
D Politics: People issues are at the

root of manyif not mostapplication security problems. For every good idea to help improve application security, theres usually someone there to strike it down. Managers and executives, in particular, are notorious for getting in the way of security and information risk management. Its the ultimate irony given their fiduciary responsibilities, but if you can work around it youll be able to do wonders for the development and QA processes. I suggest you check out these various articles Ive written for getting management on your side.
D Time management: Going beyond

the people hurdles we have to turn to ourselves and how we manage our time. One things for sure in IT: how you manage your time will make you or break you depending on your approach to the subject. There are so many factors affecting application security in your work (design, development, QA, deployment, mainte-
2 BEATING WEB APPLICATION SECURITY THREATS A SEARCHSOFTWAREQUALITY EBOOK
nance, and monitoring) that you have to set specific goals and boundaries to ensure everything is done properly and you end up with higher quality applications. Learning and eventually mastering time management is a required skill. If theres anything you learn about time management, there are two things you must not forget: 1. Just because someone throws you a ball doesnt mean you have to catch it (a tip from the late Richard Carlson). 2. Continually ask yourself if what youre doing right now is the best use of your time and, if not, move on to something productive.
D Professional development: Another personal aspect of the application security complexity equation is how you keep up with the latest technologies and security challenges. I studied and used Assembler, Pascal, and C intensely in college and for a couple of years after that. Although that was a time before application security was on our radar, I thought I knew all there was to know about programming and QA. Looking back on that now, if I assumed that was all Id ever need to know in order to excel in application security Id be fooling myself. Sure, those early days of my career built an excellent foundation. But the reality is theres so much more to learn and knowespecially with the numerous development and OS platforms youre required to work with and all security threats were up against. In my security assessment work Ive yet to interview a developer who consistently attends development or security classes, seminars, or conferences. Dont be those people. Im convinced that even though you live and breathe this stuff every day at work, continuous learning is an absolute necessity for not only keeping up, but succeeding in this field.
Figure 1: Complexities affecting Web application security
D Attack vectors: Not too long ago

all there was to worry about regarding application security was who had access to the dumb terminals and whether the users knew their passwords. My have things changed! From multiple Web browsers to mobile users to malware, applications are being attacked from every angle. And SSL and strong passwords are no longer the minimum necessary controls. You have to consider input validation, application logic, session management, and so much more. Theres literally an infinite number of ways to exploit any number of vulnerabilities in any given application. Its just a matter of time and effortboth of which the bad guys tend to have a lot of.
and security incident response. It pays to learn more about compliance these days. The good news is, under the covers, its all the same stuff simply information security best practices stated in different ways.
D Customer and business partner

demands: Compliance requirements have likely already sparked conversations with customers and business partners. If not, youll likely be involved in discussions related to the question How do we know your application is secure? A majority of the Web application security assessments I do involve this very thing: Company A is requiring an independent third-party review of Company Bs application. SAS 70 audits of a data center wont cut it. Neither will internal assessments or basic security scans. Ive heard that customer and business partner inquiries such as this are one of the most time-consuming aspects of application security. However, its part of doing business so you might as well come up with some processes such as standardized answers to security questionnaires and periodic security reviews that you can pull out when needed to help minimize the pain. The important thing is to acknowledge what youre up against. Choosing to ignore these issues will only serve to create more frustration and additional stumbling blocks. I
D Compliance requirements: No
longer are you just a developer or QA professional who can focus only on the code itself. Today applications have to be compliant with numerous regulations such as PCI DSS, HIPAA, GLBA, and Sarbanes-Oxley. If you havent experienced it already, youll no doubt be pulled into security and compliance meetings to discuss how your software meets the specific requirements of these regulations. Were not just talking about how your applications handle access controls and authentication either. Theres audit logging, separation of duties, patch maintenance, system monitoring, and even certain tie-ins with disaster recovery, business continuity,
The lowdown on PCI compliance

about you but Im getting kind of tired of hearing about PCI DSS. Yes, an information security consultant who earns his living, in part, off of compliance is saying hes tired of big component of the compliance equation. Let me elaborate. Im really just tired of two things. First, all the marketing hype the vendors are putting out there about how their products are going to magically make you compliant with PCI DSS. Secondly, all the differing opinions about what it takes to be compliant with this regulation are getting old too. There are books, whitepapers, seminars, scanning servicesyou name it. If you need to comply with PCI DSS theres a self-proclaimed expert on every corner out there who wants to help. Since youre reading this, PCI DSS probably affects you and your business in some way. As with many organizations, its likely in the context of Web security. Well, if so, youre in luck. Heres the lowdown on what PCI DSS is all about. First off, theres this
DONT KNOW
security scan requirement in PCI DSS that everything seems to be revolving around. In doing security scans myself Im here to tell you that security scans arent everything. I cant tell you how many businesses I come across that vouch theyre secure or compliant just because theyve had some PCI-certified scanning vendor
Do your homework before buying into companies that tout PCI compliance.
to run a quick scan and tell them everythings OK. Its not that simple. Ive used some of these very tools that the vendors are saying will find vulnerabilities in your applications and point out where youre out of compliance with PCI. Ive seen them not find any flaws at all while, at the same time, another vendors tool uncovers cross-site scripting, SQL
injection, and so on. Do your homework before buying into companies that tout Web scans for PCI compliance. If you show me a Web application out there that doesnt have any vulnerabilities Ill show you an application that hasnt been tested in the right ways. Relying on scans alone is one thing. Hiring a PCI Qualified Security Assessor (QSA) is something else. Youd think theyd find everything that counts but its not that simple. Information systemsespecially Web applicationscan be extremely complex and even the best QSAs out there may not uncover everything that matters. Just ask Heartland Payment Systems. This is especially true if the people doing the assessments are just out of grad school and dont have a good mix of skills to know what to look for. Another thing is that youre probably not going to have PCI police knocking on your door. No ones going to jail over failing to comply with PCI DSS. After all its an industry regulationnot a law. That said all it takes is one breach of your payment-related systems to get your business in a real bind. A business that loses credit card processing privileges in todays world is destined to take a big hit. Finally, PCI DSS is nothing more than a set of solid information security practices bundled up in a neat little package thats being pushed as yet another separate component of com-
pliance you have to deal with. Dont fall for this. You shouldnt focus on PCI DSS in a standalone fashion if your business falls under the scope of other regulations such as HIPAA, GLBA, SOX, and so on. Odds are it does. Work with your compliance
No ones going to jail over failing to comply with PCI DSS.

officer, or if youre like many other IT professionals and you are the compliance officer, try to get a handle on what other regulations your business is up against and focus on information security as a whole. This will allow you to touch on all of the important areas (risk assessment, policies and controls, visibility, automation, and so on) so you can kill two, or three, or four birds with one stone rather than addressing each regulation on its own. This is all the same stuff folks. Getting your compliance priorities in order is absolutely necessary. Just dont pour all your energy and money into security for the sake of compliance. Even though PCI DSS is a regulation with explicit requirements, you have to temper it with some good old-fashioned common sensefor thats the stuff smart security consists of. I
Introduction: Assessing your Web application security
interesting about application security. We can find the technical flaws and even have the means to fix them, but it seems like the organizational and people side of the equation gets in the way every time without fail. When it comes to locking down your Web applications, youve got to go beyond the bits and bytes and take process and politics into account as well. If you dont youll spin your wheels indefinitely until you move on to another organization, where youll likely find the same roadblocks if nothing is done about it. Web security is as much about culture and leadership from above as it is how good of a developer or QA analyst you are. We often face challenges that fly in the face of doing what really needs to be done in order to achieve reasonable Web application security such as:
HERES SOMETHING
and users to help support your Web security initiatives.
D Establishing information
security standards and policies that customers expect.
D Getting the funding to do Web

security testing the right way.
D Having the means to actually

do something with the results of your testing.
D Maintaining the momentum

to ensure application security is ingrained into daily business. These issues are not unique to any one type of business or industry. Everyone faces them. Its how you position yourself, establish your credibility, and make your case that will determine whether or not you can make things happen. One thing to keep in mind when going through the Web application
D Getting the ear of management
CHAPTER 2: ORGANIZATIONAL ISSUES AND BEST PRACTICES
security process is that you dont have to drain the ocean all at once. Simply getting the process started and slowly integrating security into your processes is the best way to go about it. Furthermore, youll want to have goals. You have to define where it is you want to go so youll know when youve arrived. Just dont forget that security is never an end result, but rather a set of processes and good habits practiced time and again. That said, lowering the number of security
flaws is an end result. And so is performing consistent security checks. Set your sights on the right areas and you can move forward with ease. There are several key factors that will help make effective Web application securityand overall information securitya reality in your business. The proven process for minimizing information risks is shown in Figure 1. Even with these recommendations many people are still too busy for Web application security. Or, they dont know where to start. There are
Figure 1: The minimum ingredients necessary for Web application security success
numerous Web security standards such as the OWASP Top 10 (especially the forthcoming risk-based 2010 version) and the SANS Top 25 that can help you get the ball rollingat least on what to look for. Beyond the OWASP and SANS lists you can turn to a standard such as ISO/IEC 27002:2005. Its higher level information security principles can be applied directly to Web application security. From security policies to incident response to business continuity and beyond, the 27002 framework shows you everything you need to be successful at Web application security. Its all a matter of making the choice to do and then making taking the time to do it right. I strongly believe that you dont need to recreate the wheelespecially when you have so many proven information security resources at your disposal. If youre too busy to start from ground zero you can still keep it simple by utilizing standards
and frameworks that other people have developed to have all you need. In the end, stay focused on the right areas. Organizational issues such as
If youre too busy to start from ground zero, keep it simple by utilizing standards and frameworks that other people have developed.
policies, procedures, and politics play a significant role in Web application security. Get into the right mindset and approach Web application security like any other system or business function then stay on top of it. You cant go wrong. I
10 steps to acing Web app security assessments
is the reason for every failure. Those words from success expert Brian Tracy ring true in so many of the Web security assessment projects Ive both witnessed and been involved in. Time management experts say that one minute of planning saves us five minutes in execution. Thats a 500% return on our time. This sounds too good to be true, but its not. Ill give an example of this practice in action in this tip. Then, Ill lay out 10 best practices for successfully assessing applications Web security. A software project leader just told me a related story, in which she detailed how much time she and her team spend on planning IT and security-related projects before they ever do a thing. She said this planning not only helps get management buy-in and helps set everyones expectations going in, but it also really makes a positive difference in the outcome of
CTION WITHOUT PLANNING
their projects. This thoughtful planning showed in their security assessment results. If youre truly willing to fight the urge for instant gratification and instead put the time in up front to
Here are 10 best practices for planning Web security assessment project. You cant afford to skip these steps.
plan things out, its virtually guaranteed that your Web security assessment projects will run smoothly, uncover the things that matter, and finish on schedule to boot. Whether youll be doing the testing on your own or hiring an outside
expert, you must diligently plan things out and get all the right people on the same page. Here are 10 best practices for planning Web security assessment project. Ive learned over the years that you cant afford to skip these steps.
4.
Will a simple vulnerability scan suffice (i.e. for PCI DSS compliance) or do we also need to perform an in-depth manual analysis to uncover the other half of the vulnerabilities that scanners wont find? Including manual analysis using a malicious mindset is the only way to do itif you want to do it right.
1.
Who is this project going to affect (before, during, and after) and can we get them in on the planning phase? Many people such as developers, marketing, and DBAs are often overlooked but need to be included.
5.
Is it going to be okay to let vulnerability scanners submit forms which could create database entries and potentially thousands of emails to multiple people? This is a side-effect thats often discovered once its too late. Its good to know going in so you can create preventative measures to block such data and emails or at least set expections.
2.
What compliance-related laws and regulations are applicable here? Are we overlooking any re-quirements in that area? PCI DSS is the obvious one here but there are many others including HIPAA, GLBA, and even SOX.
6.
When can the automated scanning be done? Commercial vulnerability scanner toolswhen used properly can be tweaked to minimize the impact on your Internet connection and server environment.
3.
Are we going to look at the system as an untrusted outsider, a trusted user, or both? Management may trust users of the system which is a dangerous way of doing business. Even worse are the vulnerabilities a trusted user could exploit you may overlook by not doing authenticated testing.
7.
How often are status updates going to be given? Ive found it to be not only the courteous thing to do but
also an important part of keeping people in the loop in these often complex projects.
8.
Will an initial findings report be delivered to the key players before the final draft report is created? If so, when? Just be patient and try to hold off requesting a bulleted draft report with few details, screenshots, or specific URLs affected. This usually just serves to generate more questions and create more work for everyone involved.
find the flaws and then deliver the report but quite another to actually act upon them to ensure the money and effort spent doesnt go to waste. The hard part of all this is carving out the time up front before getting rolling with your Web security assessment projects. Management support is certainly a key component but it really comes down to self-discipline, as Elbert Hubbard once defined as the ability to make yourself do what you should do, when you should do it, whether you feel like it or not. Its the little things that add up. Pay attention to these project details and any others specific to your business and youll certainly come out on top. I
9.
Is everything in writing? For internalsourced projects, at least have a documented plan. For outsourced projects, statement of work and signed contract needs to be in place without exception.
ADDITIONAL RESOURCES FOR CHAPTER 2
10.
Whats the exit strategy? In other words, whats going to happen once the assessment is complete and the report is delivered? This is where many projects fail. It is one thing to
q How to get management

on board with Web 2.0 security issues
q Web application
security testing checklist
Building Trust Around The Globe

When you want to establish trusted relationships with anyone, anywhere on the internet, turn to thawte. Securing Web sites around the globe with: strong SSL encryption expansive browser support multi-lingual customer support recognized trust seal in 18 languages thawte offers outstanding value on a full range of digital certicates. Secure your site today with a thawte SSL Certicate. of
www.thawte.com
2009 thawte, Inc. All rights reserved. thawte; the thawte logo; its a trust thing; thawte, and other trademarks, service marks, and designs are registered or unregistered trademarks of thawte, Inc. and its subsidiaries and afliates in the United States and in foreign countries. All other trademarks are property of their respective owners.
Introduction: Identifying and beating most common Web security attacks
of the Pareto Principlea.k.a. the 80-20 rulewhich says 80% of the effects come from 20% of the causes. We can easily apply the 80-20 rule to Web security: 80% of the risk comes from 20% of the flaws. In other words, the majority of the Web security risks stem from a small number of weaknessesmost of which we keep repeating over and over again. Theres a misperception by many, especially those in marketing and management, that Web exploits are these elaborate hacks carried out by highly technical attackers. In fact, its quite the contrary. Most of the issues I see in my workreinforced by the many Top 10 Web security vulnerability listsare simple, silly, and often stupid weaknesses that lead to serious consequences when exploited.
OUVE LIKELY HEARD
The following are the most common Web security attacks you need to be on the lookout for in your development and quality assurance processes along with what you can do to minimize the risks:
1.
Lack of input validation: Everyone knows that not sanitizing user input to filter JavaScript, SQL commands, and so on is a no-no, but this has got to be one of the biggest problems on the Web. Be it cross-site scripting or SQL injection, the ramifications of not validating input on Web forms and URLs can lead to pretty serious consequences. Ive found that you absolutely have to use a good Web vulnerability scanner such as WebInspect or Acunetix Web Vulnerability Scanner in order to find input validation flaws. There are just too many entry points and itera-
tions to test an entire website or application manually. But its not just the toolsits using multiple tools wherever possible (they all find different things) and testing as authenticated users at different role levels as
Once you find the flaws, its simply a matter of only accepting whats expected and nothing more.
well. Authenticated cross-site scripting is more difficult to exploit, but this is the area where I find the most problems with SQL injection. Just because someone has login credentials into your application you can never assume their intent is good and theyre always going to do the right thing. Once you find the flaws, its simply a matter of only accepting whats expected and nothing more.
that works just as well if not better for ferreting out weak passwords. However, finding weak passwords is time sensitive (and intensive) and highly-dependent on the dictionary you use. The problem with weak passwords is actually pretty simple to prevent. The reality is that if users have the option to create a weak password, they will. End of story. The solution is simple: dont give them that option. And ignore the complaining youll undoubtedly hear from users and management when this change is made. Its for their own good. Furthermore, build in an intruder lockout mechanism just like our operating systems have that will lock the account after 5, 10, or 15 failed login attempts.
3.
Weak login mechanisms: On a related note, entire Web login mechanisms are often vulnerable to attack. Be it hidden fields, cookies, or other session variables that are passed during the login process, theres often something that can be manipulated to escalate privileges or even bypass the login process. This goes for NTLM-based authentication, formbased authentication, and even sites with multi-factor authentication. Authentication logic thats easily manipulated by users is bad however you slice it.
2.
Weak passwords: Another common sense flaw that I see all the time is weak passwords. Commercial Web vulnerability scanners do an okay job at finding weak passwords. Theres also the freeware tool called Brutus
Although a tougher problem to fix given that the issues are so unique, weak login mechanisms can be overcome. You just need to on put your hacker hat and perform some good manual analysis using a Web proxy tool and session manipulation tool like the Firefox Web Developer plugin and youre good to go. Find the flaws and then reverse engineer a fix.
The interesting gotcha to these weaknesses is that, in many situations, theres nothing in place to actually detect them. The bad guys come in, do their thing and sometime down the road you may find out there was a Web security breach. Approach Web security from a proactive risk perspective rather than
4.
Web server configuration weaknesses: The final big Web security flaw I find goes beyond Layer 7 down to the actual server and application configurations. I often find weak OS passwords, missing patches, ports open to poorly-configured Internet services such as FTP, and so on. If you dont have a good foundation at the OS and application levels you cant expect have a secure Web site or application. In order to find the flaws beyond the application layer you need to use more generic OS/network vulnerability scanners such as QualysGuard and NeXpose. Simply run the scans, see what they find, and plug the holes. Its typically a matter of reconfiguring software, installing newer versions of Web and application servers, and hardening the OS. It wont cost you a dime, but the payoff will be grand.
The bad guys come in, do their thing and down the road you may find out there was a Web security breach.
a reactive we have to pass our compliance audit so we need to lock things down perspective. Model your application threats, use good Web vulnerability scanners, and look at your (mis)use cases by thinking like the bad guys and how they can exploit these weaknesses in your specific environment. By approaching Web security this way youll not only identify and prevent the most common attacks, but youll also find what matters the most to your business and your customers. I
Finding cross-site scripting (XSS) application flaws checklist
(XSS) is like weak passwords: the problem is widespread; the solution is relatively simple and yet the issue appears to be getting worse. I remember when XSS was this mysterious Web flaw that no one could really explain. We knew it was something bad but it was hard to put a finger on it. A decade later, XSS plagues the Internet. Everything from basic Web sites to social media systems to e-commerce applications seem to have XSS flaws in some form. Numerous studies have shown that XSS makes up the majority of Internet-related vulnerabilities. Over the past year, Ive found XSS in all but about five percent of the Web sites and applications Ive tested. This is a big deal when you factor in the ease of accessibility and exploitation, especially via phishingrelated attacks. Heres what you can do right now
ROSS-SITE SCRIPTING
to seek out and ultimately eliminate XSS vulnerabilities in your environment.
D Understand the vulnerability so

youll know what youre up against and what to look for. As with weak passwords, XSS is pretty basic.
D Assemble your toolset. XSS is

something that can turn up on any Web form or input area on your site or application. Its unreasonable to assume youre going to be able to find all of the input areas and throw every possible iteration of XSS at them. You have to have a good Web vulnerability scanner such as HPs WebInspect or Acunetix Web Vulnerability Scanner, just to name a couple. Based on my experience, youre not going to find many XSS flaws, if any, if youre not using a dedicated Web vulnerability scanner and are just using a more generic vulnerability scanner that touts Web capabilities often in the name of PCI DSS scans.
D Scan your systems as an untrusted outsider. I see a lot of XSS in Web applications behind authentication mechanisms. This no doubt highlights input validation issues but its less of a concern given that the required login can stop the automated aspect of XSS attacks. However, this is changing due to the emergence of persistent XSS, malicious code thats stored in a database and made accessible via rich Internet applications.
unsuspecting user or third-party in the same way spammers take advantage of random open SMTP relays to indirectly carry out their misdeeds against others.
D Dont focus solely on JavaScript.

Im starting to see more VBScript and Flash-induced XSS. Its pretty rare, but I suspect thatll change as applications become more complex. Make sure youre scanning all parts of your site and/or application with a tool that can uncover all XSS regardless of the language thats facilitating it.
D Test every public-facing system

whether or not its critical. The essence of XSS is not necessarily tied to the importance or value of the system. Its the fact that youre enabling the bad guys to exploit a flaw in your environment to take advantage of an
D If youve thoroughly scanned

your entire site/application and nothings turning up, you can check for XSS manually by entering the following into form fields: < script > alert (XSS!)< /script > Its really basic and not guaranteed, but I have found XSS that Web vulnerability scanners have missed by using this technique. The good news is that XSS often doesnt place sensitive back-office information at risk. Its more of a risk to your users and to unsuspecting third-parties on the client side; but it could ultimately lead to theft of login credentials and session information, which creates an entirely new dilemma for your business. Given the simple solutions, its still not a risk worth taking. I
q Web server weaknesses

you dont want to overlook
q Web security problems: Five

ways to stop login weaknesses
q Fixing four Web 2.0 input

validation security mistakes
q Essentials of static source

code analysis for Web applications
Introduction: Hacking your own applications
ways to improve the security theres nothing better than using hacking tools and techniques to bring out the worst in your Web applications. Not audits, not source code analysis, and not even vulnerability scans, but instead ethical hacking. Approaching Web security with a malicious mindset is the tried and true way of finding all the security flaws that count in your environment. It essentially guarantees that youll take your Web application security to the next level and beyondif you do it the right way. The key to successful hacking requires the right mindseta malicious mindset. You have to be able to think of ways to exploit weaknesses in the system that the average person might not be thinking about. Things like:
F ALL THE
D Manipulating URL variables

to gain access to other accounts.
D Looking at a shared computers

Web browser history file for HTTP GET requests that cache login credentials.
D Tampering with cookies used

for session management in order to escalate your privileges.
D Trying default or common

user IDs and passwords when logging in.
D Gaining access to the administrative portion of an application and erasing audit log files that track user logins and changes. The possibilities are endless. My point is that the bad guys on the Internet and inside your organization are thinking maliciously and you have to do the same if you're going to defend against them.
D Removing maximum field lengths

for form inputs to see how the application reacts.
Once you establish the mindset you can proceed with the ethical hacking process. Its actually pretty simple to understand and follow. This requires the following:
1.
Get the key players on board and ensure everyones expectations are set. The last thing you want to do is start down the path of ethical hacking without approval and buy-in of management. Its virtually guaranteed youll lose support or not be able to effect any changes if you do.
Web proxy, and a browser manipulation tool such as Firefox Web Developer. Ive also come to rely on multiple Web vulnerability scanners, the Brutus password cracking tool, a hex editor, and even some of the tools inside in the BackTrack toolset. The quality of the tools will determine the outcome of your hacking efforts.
4.
Run your automated vulnerability scans. Check the OS and network levels in addition to the application layer. Use multiple scanners when possible and be sure to test as both an untrusted outsider as well as trusted users at all role levels. An important note related to authenticated scanning: make sure your Web vulnerability scanner actually authenticates into the application. Ive see login and startup macros fail more often than not. It appears that the scanner logged in, but actually did not, which creates a false sense of completion and security.
2.
Inventory all of your Web systems. Youll know the obvious ones but its often those obscure and forgotten about systems deep inside your network that create considerable risks. Talk to the different system managers to determine whats where. To validate your findings and uncover others that people have forgotten about, I suggest running a port scan to search for common Web ports (TCP 80, 443, and 8080) at a minimum. Certain Web vulnerability scanners have discovery tools built in as well.
5.
Perform your manual analysis. This is where the true art of ethical hacking comes into play. Youll take what your vulnerability scanners found, validate their results, and then dig in further into areas the scanners discovered as well as other areas that scanners dont understand. Things like I men-
3.
Build your toolset to include, at a minimum, OS/network vulnerability scanner, Web vulnerability scanner, a
tioned above regarding the login mechanism, session management, passwords, URL manipulation, and so on. As with your automated scans, do your manual analysis as an untrusted outsider as well as trusted users at all role levels. If your automated scanning took 1 or 2 days to complete, this phase of your testing can easily take twice that amount.
tion on your main Web portal which needs attention immediately. Once youve completed your testing efforts and remediated the vulner-
6.
Once youre done (which can be tricky to determine since you could conceivably go on forever) you have to focus on whats urgent and important. In other words, focus on those Web vulnerabilities that are exploitable or potentially exploitable on the sites and applications that matter. For example, you might find cross-site scripting on a test application located on the QA network which would likely be a low priority. On the other hand you may find SQL injec-
Focus on the Web vulnerabilities that are exploitable on the sites and applications that matter.
abilities that matter to your business itll probably be time to start the process over again. I often see a lack of follow through in this stage of the game which effectively negates any benefits youve gotten out of your efforts. Think ethical, malicious, and consistentthats the type of hacking you want to do. I
Hack maliciously to boost your softwares security
know the right way to go about testing the security of Web applications. Perform an external scan, the auditors recommend. Just use our vulnerability scanner, the vendors proclaim. Do a peer review of the source code, the quality assurance (QA) analysts declare. And then there are the government, industry regulatory, and standards bodies who believe they know what it takes to secure an app. Regardless, its their way or the highway. Ha! With everything else being equal, unrelenting and almost aggressive malicious attacks are the absolute best way for uncovering Web security holes. In this tip, well cover why you must literally go through your Web systems and throw everything you possibly can at them. This tip will get you started on using malicious manipulation to boost security. In forthcoming tips, Ill show how to do malicious hacking in various different
VERYONE CLAIMS TO
software development and testing scenarios. Theres so much information available for uncovering Web application flaws, but theres no good place to start. So how can you, the security admin, developer or IT manager, filter through the noise and distill exactly what needs to be done to find the Web flaws that count? Let me be clear, its simple. There is no one best way to go about it. As lawyers and consultants like to say, it all depends. It depends on the type of business youre in and the regulations you fall under. It also depends on what type of Web presence you have and how sensitive information is processed, stored or otherwise passed through your system. It depends on how much management supports your efforts and, frankly, how much money you have to spend. Every organization and every Web application is different. Ironically, this is one of the things that management
misunderstands the most. Web security testing is not a black- and-white science. Its just as much an art, and one that requires good tools, creativity, along with a confident security assessor. Choosing the one thing that stands out as being the most important for uncovering the obvious and not so obvious Web vulnerabilities is pretty easy. Some of this requires Web vulnerability scanning tools like WebInspect, Acunetix WVS and N-Stalker. No matter how good you are with Web apps and security, theres still no replacing the requests that tools such as these can throw at an application. They can mimic hack attacks like no human possibly could. Dont let me steer you in the wrong direction though. Based on my experience testing Web applications over the years, the ability to poke, prod, and control an application with illgotten gains in mind is the key for making things happen. Its required if youre going to find the flaws that really matter. At the heart of this is manipulation, which is often a matter of just the right poking and prodding to see how the application trusts you and what it spits back. This will rarely require special hax0r skillz. Its merely a matter of understanding the basic operation of Web applications and thinking of creative ways to hack and throw just the right jabs to force them into submission.
Many, many times Ive tested Web applications with automated scanners, only to realize I wasnt even halfway home. Beyond the scanning phase, Ive seen situations such as
No matter how good you are with Web apps and security, theres still no replacing the requests that tools such as these can throw at an application.
creative URL manipulation, weak passwords or sensitive files stored in download folders that have turned two to three day Web security reviews into week-long plus analyses bordering on data breach situations. All because of some basic hackingmanipulationof these applications that wouldve gone undiscovered otherwise. I cant stress enough the value of in-depth ethical hacking of your Web applications. Theres no replacement for manual manipulation; just you and your Web browser. Get past the onescan-fits-all mindset. Its dangerous and itll come back and bite you if you rely on just the basics to get by. I
Introduction: Security best practices for todays Web applications
todays Web applications is both a blessing and a curse. On the positive side, were now able to do things with dynamic Web applications that seemed impossible in the static
HE MATURITY OF
Figure 1: The proper approach to Web application security
world of just a few years ago. On the negative side, were now seeing Web application complexities introduce security vulnerabilities beyond our imagination. Its becoming increasingly difficult for information security professionals, developers, and quality assurance analysts to get their arms around these issues. What can you do to minimize security risks with rich Internet applications and in the cloud? It takes a reasonable and well thought out approach to do it right. Figure 1 shows, in a nutshell, what you have to do. Like any other ongoing business process, these are things you have to do on a periodic and consistent basis. Lets look at each of these areas more closely.
1.
Obtain buy-in: If you dont have the ear of the people who count, then
youll be fighting a losing battle trying to secure your applications. Most importantly, you have to get management on board. If the people approving the budgets and writing the checks dont understand why application security is a business concern, then everything is for nothing. Without monetary, human resource, cultural, and political support from the powers that be you might as well just rely on passwords and SSL to get you through (hint: thats not a good longterm solution). You may even need to get user buy-in especially when it comes to security controls requiring business process changes and potential usability issues. Also, depending on which side youre on (information security, development, or QA) youll need to get your colleagues on board. Making sure everyone is on the same page working toward the same goals should be your main goal.
3.
Run automated scans: Web vulnerability scanners are absolutely essential for finding both the low-hanging fruit as well as the complex input validation flaws, such as XSS and SQL
SECURITY TESTING TOOLS

There are tons of options available but the following are ones that Ive found to work well. Click on the links below for additional information. Web vulnerability scanners Acunetix Web Vulnerability Scanner I N-Stalker I NTOSpider I WebInspect
I
2.
Choose your tools: Just like you wouldnt use inferior programming languages or IDEs to develop your applications you cant afford to not have good security testing tools. Having the right Web security tools such as vulnerability scanners, proxies, and source code analyzers will make or break your Web application security efforts. (See Security Testing Tools for a list of tool options.)
Web proxies I Burp Proxy I Paros Proxy I WebScarab Source code analyzers I Checkmarx I SecurityReview Dont rule out open source toolsespecially the Web proxies I list abovebut know that, by and large, youre going to get what you pay for.
injection that would otherwise be impossible to uncover. Just know that you have to run the scanners often and multiple scanners are usually required to find everything that matters.
Sadly, this step is skipped or not done properly and the application vulnerabilities live on. The only way youre going to produce better code, and thus, more secure Web applications is to learn from your mistakes and continually improve.
4.
Perform a manual analysis: Automated scanners can only find so much. A sharp human eye and manipulative ethical hacking techniques are essential for finding all the other flaws that vulnerability scanners arent smart enough to detect. Look for things like login mechanism weaknesses, application logic problems and privilege escalation via session manipulation.
7.
Report to your stakeholders: Keeping management, auditors, regulators, customers, and business partners in the loop on what youre doing/finding/improving upon is a great way to get continued support for application security. Its also a great way to help create a competitive advantage for your business. People are going to ask How secure is the application? anyway so it doesnt hurt to be proactive and be able to provide the current security status when the time comes. Complexity introduces weakness and oversight which, in turn, create security risksall things we cant afford to take on in business today. Finding and fixing Web application flaws is becoming more difficult but its not an insurmountable problem. If you approach it in a mature and methodical way you can find the issues that matter and move on. The method I discuss above has been proven successful time and again. Be it for best practice or compliance, its simply a matter of choice. I
5.
Check source code: Once youve completed your vulnerability scanning and manual analysis, a nice way to wrap things up is to look at the actual source code. Some analyzers look at raw source code while others perform binary analysis that mimics real-world execution. Both are very good at finding things that youd be hard-pressed to find otherwise.
6.
Fix what you've found: Once you find where the weaknesses are, take the necessary steps to plug the holes.
Rich Internet applications security testing checklist
technologies like Ajax, Flash and Web services being all the rage, rich Internet applications (RIAs) are popping up everywhere. More developers are creating rich apps inhouse and integrating such third-party code into existing environments. However you slice it, RIAs and Web 2.0 technologies cannot be ignored. Likewise, we cant ignore the slew of security flaws RIAs tend to introduce. Rich Internet applications not only place more control into the users hands, they also broaden the attack surface and open previously nonexistent entry points into networks. The big thing with rich Internet applications is that you cant just scan em and forget em. Current scanning technologies for penetration testing and code analysis are still pretty limited relative to the complexity of these applications. But dont worry! You can still check for the security holes that
ITH WEB 2.0
matter, and a few more to boot, if you approach your Web 2.0 code and technologies from all the right angles. In this checklist, you can find out what you can do to find and eliminate security flaws from your rich Internet applications.
D Understand the scope of the vulnerabilities rich Internet applications present. Theyre similar to common Web vulnerabilities but often have their own twist. Common rich Internet application flaws include XSS, SQL injection, embedded passwords in media files, as well as easilymanipulated client-side variables and exposed business logic.
D Gather good tools. There are

numerous free and commercial options. Among my favorite freebies are the following:
I
Firefox Web Developer is a Firefox plugin for manual manipulation of client-side code.
SWFScan is a tool for decompiling/analyzing Shockwave Flash (.swf) files. WSFuzzer is a tool for performing fuzzing of SOAP Web services. My favorite commercial tools are HPs Acunetix Web Vulnerability Scanner. These are all-in-one Web vulnerability scanners that include specific tools for further manual analysis. Plus theyre well-maintained so you know youre going to be scanning for the latest and greatest Web 2.0 flaws.
that the first one completely missed. This is especially true for rich Internet applications. Ive also found that using a higher-level vulnerability scanner such as QualysGuard or Nessus can often find server and application weaknesses that dedicated Web scanners dont know about.
D Scan your Web services. Theyre

easy to configure and forget, but XML-based Web services can be one of your greatest Web security weaknesses. Theres something for everyone, ranging from XPath injection to SQL injection to command execution to password cracking. Tools such as WebInspect, Acunetix and others can scan for specific Web services flaws, and I highly encourage you do to do those scans.
D Scan your systems as an untrusted outsider as well as a trusted user. That said, you have to understand that your scans may not find each and every flaw when you set them on auto-pilot. If possible, set your scanner to "manual crawl" mode and step through the application yourself, clicking on every link and submitting every form. This will allow your scanner to find parts of the application itd never be able to find otherwise. The manual crawl process can take a while in complicated applications but its the only reasonable way to get your Web vulnerability scanner(s) to find what matters.
D Scan your Flash, using SWFScan,

and other media files, using Web and general network vulnerability scanners. Even your local antivirus software can highlight security flaws in these files when you download or run them. Ive seen and heard about all sorts of security flaws related to rich media. Everything from embedded encryption keys to business logic to malware can turn up in these files, so be sure to include them in the scope of your testing.
D Use multiple Web vulnerability

scanners if you can. I often find vulnerabilities using a second scanner
D Check for other common flaws

that affect all Web applications
regardless of the technologies being used. This includes weak passwords, lack of intruder lockout which facilitates password cracking, weak authentication mechanismsespecially home-grown multi-factor systemsform manipulation, URL tampering and sensitive files stored on the server unprotected. Work through each of these stepsand ensuring the issues are remediatedwill bring you that much closer to reasonable security in your rich Internet applications. Perhaps most importantly, never let your guard down. The security issues surrounding rich Internet applications are only going to become more complex. Getting your arms around the
q Mobile, Web app QA testing

tips for handling operating system changes
q Web server weaknesses

you dont want to overlook
q Free Web proxy security

tools software testers should get to know
issues that matter now will allow you to scale your efforts as your applications continue to grow. I
ABOUT THE AUTHOR: Kevin Beaver is an information security consultant, expert witness, as well as a seminar leader and keynote speaker with Atlanta-based Principle Logic, LLC. With over 20 years of experience in the industry, Kevin specializes in performing independent security assessments revolving around compliance and managing information risks. He has authored/co-authored seven books on information security including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley). In addition, hes the creator of the Security On Wheels information security audio books and blog providing security learning for IT professionals on the go. Kevin can be reached at www.principlelogic.com.
R ESOU RCES FROM OU R SPONSOR
q Extended Validationthe New Standard in SSL Security q Sign your Code and Content for Secure Distribution Online q Get a Free SSL Trial Certificate from Thawte
About Thawte: As a leading global certificate authority, Thawte provides online security trusted by millions around the world. Expert multilingual support, robust authentication practices, and easy online management make Thawte the best value for SSL certificates and code signing certificates. In 2004, Thawte became the first certificate authority to recognize and secure Internationalized Domain Names (IDNs), enabling more people to navigate the web securely in their own language. The Thawte Trusted Site Seal, available in 18 languages, helps users verify the identity of web sites in their own language. Because SSL is our core business, we constantly improve our products to deliver the tools and features our customers want and need. Our data centers and disaster recovery sites provide unsurpassed customer data protection.

Beating Web Application Security Threats

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Beating Web Application Security Threats

Uploaded by

Copyright:

Available Formats

BEATING WEB APPLICATION SECURITY THREATS

New Web application security challenges

Assessing your Web application security

Beating common Web security attacks

Hacking your own applications

Overview of best practice tips and checklists

CHAPTER 1: NEW WEB APPLICATION SECURITY CHALLENGES

CHAPTER 1: NEW WEB APPLICATION SECURITY CHALLENGES

Introduction: New Web application security challenges

CHAPTER 2: ASSESSING YOUR WEB APPLICATION SECURITY

CHAPTER 3: BEATING COMMON WEB SECURITY ATTACKS

CHAPTER 4: HACKING YOUR OWN APPLICATIONS

CHAPTER 5: OVERVIEW OF BEST PRACTICE TIPS AND CHECKLISTS

D Politics: People issues are at the

D Time management: Going beyond

2 BEATING WEB APPLICATION SECURITY THREATS A SEARCHSOFTWAREQUALITY EBOOK

CHAPTER 1: NEW WEB APPLICATION SECURITY CHALLENGES

CHAPTER 1: NEW WEB APPLICATION SECURITY CHALLENGES

CHAPTER 2: ASSESSING YOUR WEB APPLICATION SECURITY

CHAPTER 3: BEATING COMMON WEB SECURITY ATTACKS

CHAPTER 4: HACKING YOUR OWN APPLICATIONS

Figure 1: Complexities affecting Web application security

CHAPTER 5: OVERVIEW OF BEST PRACTICE TIPS AND CHECKLISTS

3 BEATING WEB APPLICATION SECURITY THREATS A SEARCHSOFTWAREQUALITY EBOOK

CHAPTER 1: NEW WEB APPLICATION SECURITY CHALLENGES

D Attack vectors: Not too long ago

CHAPTER 1: NEW WEB APPLICATION SECURITY CHALLENGES

D Customer and business partner

CHAPTER 2: ASSESSING YOUR WEB APPLICATION SECURITY

CHAPTER 3: BEATING COMMON WEB SECURITY ATTACKS

CHAPTER 5: OVERVIEW OF BEST PRACTICE TIPS AND CHECKLISTS

4 BEATING WEB APPLICATION SECURITY THREATS A SEARCHSOFTWAREQUALITY EBOOK

CHAPTER 1: NEW WEB APPLICATION SECURITY CHALLENGES

The lowdown on PCI compliance

CHAPTER 2: ASSESSING YOUR WEB APPLICATION SECURITY

CHAPTER 3: BEATING COMMON WEB SECURITY ATTACKS

CHAPTER 4: HACKING YOUR OWN APPLICATIONS

CHAPTER 5: OVERVIEW OF BEST PRACTICE TIPS AND CHECKLISTS

5 BEATING WEB APPLICATION SECURITY THREATS A SEARCHSOFTWAREQUALITY EBOOK

CHAPTER 1: NEW WEB APPLICATION SECURITY CHALLENGES

CHAPTER 1: NEW WEB APPLICATION SECURITY CHALLENGES

CHAPTER 2: ASSESSING YOUR WEB APPLICATION SECURITY

CHAPTER 3: BEATING COMMON WEB SECURITY ATTACKS

CHAPTER 4: HACKING YOUR OWN APPLICATIONS

CHAPTER 5: OVERVIEW OF BEST PRACTICE TIPS AND CHECKLISTS

No ones going to jail over failing to comply with PCI DSS.

6 BEATING WEB APPLICATION SECURITY THREATS A SEARCHSOFTWAREQUALITY EBOOK

CHAPTER 2: ASSESSING YOUR WEB APPLICATION SECURITY

CHAPTER 1: NEW WEB APPLICATION SECURITY CHALLENGES

Introduction: Assessing your Web application security

CHAPTER 2: ASSESSING YOUR WEB APPLICATION SECURITY

CHAPTER 3: BEATING COMMON WEB SECURITY ATTACKS

CHAPTER 4: HACKING YOUR OWN APPLICATIONS

CHAPTER 5: OVERVIEW OF BEST PRACTICE TIPS AND CHECKLISTS

and users to help support your Web security initiatives.

D Getting the funding to do Web

D Having the means to actually

D Maintaining the momentum

D Getting the ear of management

7 BEATING WEB APPLICATION SECURITY THREATS A SEARCHSOFTWAREQUALITY EBOOK

CHAPTER 2: ORGANIZATIONAL ISSUES AND BEST PRACTICES

CHAPTER 1: NEW WEB APPLICATION SECURITY CHALLENGES

CHAPTER 2: ASSESSING YOUR WEB APPLICATION SECURITY