Web Security…Are you at risk?

Introduction

This White Paper is about security on the Web. It’s not for geeks or IT managers, it is targeted to those of you, like me, who are still confused about cholesterol and what it means when we have good and bad cholesterol, what the combined totals mean and, to be honest, just want to know if we are eating too many cheeseburgers. Most of us get our first, and perhaps, only introduction to Web security when our Yahoo email account is hijacked and all of our friends, relatives and business associates receive a personal email touting some embarrassing product or service. This is always an embarrassing mystery to most of us.

Like my cholesterol levels, I just want to know if my company web site will be attacked by a bunch of bored 10^th graders or what all those folks in foreign countries are going to do with the credit card receipts they found on my server.

The good news is that you can stop wondering whether your company web site is safe from attack; you can pretty much assume it is not. The Web is infested with really smart geeks who spend endless hours figuring out how to attack Web sites, sometimes just for the challenge. They just haven’t gotten around to your site yet.

Even the Department of Defense gets hacked, and they have as much security as money can buy. Chances are your site falls somewhere between totally unsecure and pretty secure. Your reasonable expectation, however, should be that your site is secure enough to fend off not only those 10^th graders but almost everyone except the very skilled and persistent hacker. More good news is that this expectation should be within most company budgets; security is not impossibly expensive as long as it is part of the original plan. It is, however, very hard and expensive to retrofit a Web site for security after it has been built.

The remainder of this paper will talk about security flaws (hopefully in an understandable way) and give you an idea of the questions you need to ask of your Web designers and developers the next time you build a new Web site or worry about your current site.

Web Security Flaws 101

The next few pages will discuss some of the more obvious and potentially damaging security flaws that many Web sites suffer from. These will include:

• Communication Encryption
• SQL Injection
• Broken Access Control
• Poorly Constructed Session Cookies
• Information Leakage
• Cross-Site Scripting

Communication Encryption

Most of the time, the data that passes between your computer and the target server can be seen and read by anyone who cares to look. Think of this as the electronic version of walking around the mall with your credit card number pinned toyour shirt. Usually this is OK; no one really cares what news Web sites you visit or how your fantasy football team is doing. On-line banking and Web purchases (with your credit card numbers), amongst many, are another issue.

Unprotected data across the Web is called Clear Text and means exactly what it sounds like. Your login sequence, bank codes and whatever else you enter is easily seen by whoever might want to take a look.

The good news is that visibility of unprotected text is one of the easiest security flaws to fix and, even better, can be easily implemented on existing sites. You may have heard of the term SSL (or Secure Sockets Layer) bounced around when Web security is mentioned. All this means is that your browser and the server have agreed on a secret code and that all information passing between the two is encoded such that even a serious hacker cannot get to the information. The next time you do on-line banking look at the URL (funny text string at the top of the browser); you will see the first few characters are https:, not the http: you are used to seeing. This addition of the ‘s’ is an indication that your data is being encrypted; a good thing when doing on-line banking.

The bad news is that many people, including a lot of IT professionals, believe that SSL solves their security problem and the world is safe from hackers. Unfortunately, this is not the case. It just means you are no longer passing your credit card numbers to strangers. There is a lot more to worry about.

SQL Injection

With a name like SQL Injection, you might think the associated security flaw must be a mean one. Yep, you would be correct, it’s a mean flaw. As you may know, most Web sites store data in a database. Your Web site retrieves or stores this database data using a language called SQL (Structured Query Language). This is a very complex and powerful language that allows a software developer to do almost anything with your data. For example, when a Web user types in her comments, these are stored in the database using SQL commands so they can be remembered later.

A major problem may arise, however, when a malicious user enters text into a comment field in which that text contains unexpected data. For example, instead of the comment “WDDinc is a great company.”, the user might enter “SELECT * FROM members; DROP members”. If done with care (more text surrounds the line), this might result in erasing all of the names and passwords in the database. You can only imagine the really mean things am ambitious hacker can do.

SQL Injection is a possibility everywhere in your Web site where users are allowed to enter data; think of these simple text boxes as an entry points into your database’s soul. The problem with a Web site that is subject to SQL injection flaws, aside from the damage a malicious user might do, is the work involved in eliminating the threat. While it is possible to develop a Web site that prevents SQL Injection, it is often very hard to change the underlying software after the site is built.

Broken Access Control

Many Web sites have areas that are private and must be entered through a login procedure. For example, I cannot check on my eBay order unless I have logged in as me. The problem with some Web sites, however, is that I may be able to go directly to the private portion without logging in first. This might be as simple as entering the URL for the private area (i.e., https://findme/admin/modules/orders/). This might allow me to skip over the login procedure entirely and go directly to the orders page.

Other Access Control problems arise when the site allows weak passwords or easily guessed passwords. My friend’s daughter likes to use her name and birth year as her password on every site that requires a login. This password is not so hard to guess – I have encouraged her to be a bit more creative. Another solution would be to require passwords that are more detailed than this.

One additional problem may be the fact that the login screen does not restrict the number of invalid login attempts. Given the fact that many Web sites use your email address as the login name a hacker, who already knows you email address, may be able to figure out the password just by trying thousands of possible passwords. This attack is easily implemented with an automated password script that depends on the fact that there is no limit on the number of times a login sequence may be tried.

Increased password strength requirements are easily implemented (even after the site is complete), as is a limitation on failed login attempts.

Poorly Constructed Session Cookies

Session Cookies are those small files that a Web site puts on your computer so that it can remember who you are. As disappointing as it may be, you are not the only person buying something from the Amazon Web site. In fact, there might be hundreds of thousands o

f customers logged into Amazon at the same time. When you buy a CD, wander around the site for a while, and then go to checkout, Amazon needs some way to remember who you are. One of the ways Amazon (and other Web sites) remembers who you are and what you have done, is to save a Session Cookie on your computer that contains an identifier that is unique to your current buying session. Sometimes a Session Cookie will even let you leave a Web site and will automatically log you back in when you return later.

Session Cookies are a necessity of the Web, but provide more than their share of risks. The most obvious risk is the fact that anyone using you computer after you leave for the day may be automatically logged back in as you.

A less obvious risk is the fact that a malicious user might be able to steal your session identifier in any number of ways. Your Session Cookie is just a small file, it would be simple to copy that file from your computer to another computer and pretend you are connected to the server, just from a different computer. Another risk would occur if the session identifier found in the Session Cookie (your identity) is easily guessed. If I look at my Session Cookie after a few logins and realize each subsequent cookie had an identifier that was incremented each time (e.g., 47, 51, 59) I could change my own Session Cookie to fake an identifier of 67; that might let me steal someone’s session in the near future.

There are ways to protect against a Session Cookie being used by someone to pretend they are someone else. These include making the identifier in the Session Cookie very large and very random (impossible to guess). The Server can also check to make sure the Session Cookie is being used from the originating computer. Session Cookie security protection is not difficult to implement, it is just forgotten by most developers.

Information Leakage

It is often a software developer’s desire to give as much information as possible to a Web site user, regardless of whether that information has any value or not. The most frequently seen symptom of this is a response to a failed login attempt that indicates the name portion of the login attempt was good but the password was wrong. While helpful to the user, this just makes a hacker’s life so much easier; now all they need to do is guess the password since they know the name is correct.

Web sites will divulge an amazing amount of private information if you just know how to ask; much of this information is unneeded and just adds to the potential for a security breach. The more difficult information leaks to eliminate are the error messages we sometimes see when we enter incorrect data. These are the ones that replace the entire browser screen with programming language-like text – these are often referred to as crashes. The clues in these crash reports are a hacker’s dream.

Information Leakage is either a result of a trusting sole trying to be nice or sloppy development that allows a Web site to fail in ways that reveal too much data. In the former case, it is just a matter of refining error messages to hide excessive information. In the later case, the Web site may require extensive work to limit system crashes and, if a crash does occur, present minimal information.

Cross-Site Scripting

This is the sneakiest security risk I will address. Before we talk about Cross-Site Scripting, I must say this is the one form of security attack that I admire the most, primarily because of its cleverness and subtlety. A recent statistic indicates that 70% of today’s Web sites are vulnerable to a Cross-Site Scripting attack.

The key word in this security flaw is ‘Scripting’. This attack is made possible by tricking either a Web site user or the site itself into running a malicious script. A Web site display (what you see in your browser) is either made up of content sent from the server to the user’s browser or small programs (scripts) that are run on the user’s computer under the control of the user’s browser; JavaScript is a well-know scripting language used for these purposes.

An example of a simple implementation of a Cross-Site Scripting attack would be a hacker entering a Blog entry that contains a JavaScript program (added by the hacker). Every time a regular user goes to that Blog entry the JavaScript program would be run; perhaps with devastating effects on the unaware user. The effect is that the script appears to be run by the regular user, bypassing all of the securing controls mentioned above.

An alternative form of this attack is when a hacker tricks a regular user into going to a malicious site while that user is logged into your Web site. Any JavaScript that is run on a malicious site is now able to pretend it is the logged-in regular user; anything the regular user could do (i.e., on-line banking) can now be done by the JavaScript.

Protecting against Cross-Site Scripting (and its sibling, Cross-Site Request Forgery) is an effort that is best made as the Web site is being developed. Understanding what Cross-Site Scripting is, protecting against it in software, and then testing to make sure the site is truly protected requires specialized knowledge and experience that is rare amongst Web developers and testers.

Conclusion

It’s a mean world for Web sites out there. The potential security flaws I noted above are just the few that I could describe without hurting my head, there are many more. While you should keep in mind the fact there is no way to entirely protect your Web site from hackers, it does makes sense to protect your site from all but serious attacks.

My strong recommendation for anyone building a new Web site, whether it is a brochure site or one processing serious business transitions, is to start with the idea that you need a secure site. As you may have seen from the notes above, it is very difficult to retrofit a site for security. The additional cost for a new, secure site is not on the development side, but on the security testing as the site is being built.

When you talk to a Web development firm about your new Web site, ask them about security and what will go into your site to limit security threats. If all they do is talk about SSL then assume you have the wrong folks. Adding just SSL is the same as checking your tires for proper air pressure before a long drive; it’s easy to do and you can always check your tires when you get to Pennsylvania, it’s just not enough. You probably should have checked the oil, fan belts and lots of other things that would have stranded you in Zanesville.

Developers who understand security are rare. Testers who understand security are even rarer. If you have concerns about your current Web site or are looking to build a new site, WDDinc might be just the company to help you frustrate those 10^th graders. Give us a call.

Security Terms Glossary

• Broken Access Controls – This security vulnerability involves cases where the application fails to properly protect access to its data and functionality, potentially enabling an attacker to view other users’ sensitive data held on the server, or carry out privileged actions.
• Broken Authentication – This category of security vulnerability encompasses various defects within the application’s login mechanism, which may enable an attacker to guess weak passwords, launch a brute-force attack, or by-pass the login altogether.
• Cross-Site Request Forgery (CSRF) – Cross-Site Request Forgery is an attack that tricks the victim into loading a page that contains a malicious request. It is malicious in the sense that it inherits the identity and privileges of the victim to perform an undesired function on the victim’s behalf, like change the victim’s e-mail address, home address, or password, or purchase something.
• Cross-Site Scripting (XSS) – This security vulnerability enables an attacker to target other users of the application, potentially gaining access to their data, performing unauthorized actions on their behalf, or carrying out other attacks against them.
• Information Leakage – This involves cases where an application divulges sensitive information that is of use to an attacker in developing an assault against the application, through defective error handling or other behavior.
• Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL) – These are cryptographic protocols that provide security for communications over networks such as the Internet. TLS and SSL encrypt the segments of network connections at the Application Layer to ensure secure end-to-end transit at the Transport Layer.
• Password Hash – A cryptographic hash function is a procedure that takes a user password and translates it into fixed-size bit string. It is this string that is stored in the database instead of the actual password. Depending on the encryption used function, this may make the cracking of passwords close to impossible.
• Session Cookie – Websites typically use session cookies to ensure that a client computer is recognized when it move from page to page within one site and that any information the client has entered is remembered.

• SQL Injection – This security vulnerability enables an attacker to submit crafted input to interfere with the application’s interaction with back-end databases. An attacker may be able to retrieve arbitrary data from the application, interfere with its logic, or execute commands on the database server itself.

For more information, I am happy to have myself and my team discuss Web security with you. I can reached at 317-578-1621 x24 or at mtschohl@wddinc.com

-Mike Tschohl