- OWASP

- searchsecurity.techtarget.com

- By Tim Wilson, Darkreading

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

Many of our clients (and some others) have asked what is so different from this and staff augmentation. The answer: A LOT!

Staff augmentation services work as follows. The client will call their staffing vendor and say they need a contractor for a project. For this example, lets say a .NET developer. They staffing firm will scour the job boards searching for a person/candidate that fits the job description. They will send many resumes to the client for review (the scary part is most staffing companies never even interview the candidate), until the client feels comfortable with one and decides to move forward. The staffing company hires the candidate and works out a contract with the client at an hourly rate and a duration of time. The staffing company then contracts the candidate to the client at,  lets say $100 per hour for 12 months.

The problem that I see with this model is the risk associated with it on three fronts:

The first is that the candidate is typically poorly evaluated (if at all) by the staffing company. The staffing company hires the candidate as a W2 employee so that it can sell that they are providing their full time employees as a consultant to their client. When the project is complete, the contractor is typically laid off.

The second risk is on the client side. It is really more of a question of the value of the service. If the 12 month project the contractor is on contains enough work in their specialty (in this case .NET), things should be fine. Many times though, the client will have a few new projects pop up, or have a shift in the current project that get away from the core skills of the contractor. “We decided to add a new feature that will be in PHP.” Now the client has a contractor that has no ability to do the work, and are forced to get another contractor (and pay for it) to complete the project.

The third is that you are 100% reliant on a single contractor. If he/she is sick, you get no work done, regardless of a tight deadline. If he/she quits, you have to wait for the staffing company to recruit a new candidate (followed by a potential 2 week notice).

To me, there is a lot of risk with this model. Unless you can guarantee that the project will never shift, it might be risky.

Retained Services work a little bit differently and remove a lot of the risk for clients. When one of our clients signs up for retained services, they have access to all of my staff. Using the same terms from the staff augmentation example above, the client will sign a 12 month retained services contract with us at a rate of $100 per hour, with a minimum of 160 hrs per month (40 hrs/week). Our clients can use our .NET developers, PHP developers, Java Developers, etc any way they choose. They can use multiple resources and go above the 160 hrs per month, and don’t have to pay overtime! If a projects shifts scope, our clients can call us and say “I need a PHP resource for 2 days.” We truly become a software development partner for our clients, a true extension of their business.

If any of our staff takes a few days off due to illness, or even decide to leave the company, we can immediately deploy one of our other staff members. You don’t have to wait. Your timelines stay intact.

One of our clients has approximately 40 projects on the table, all of which are fairly small and require approximately 10 different technology skills to complete them. This would be a staff augmentation nightmare. Staffing companies don’t like the headache of  recruiting potentially 10 different people for this many three day to 10 day projects. It cost more money to find the contractors than the profit made. With our retained services, the recruiting costs are non-existent. We already have the staff to deploy.

From a client perspective, we feel it makes more sense to call a vendor and say “we have 40 small projects in many different technologies, can you help?” and have your vendor say “sure, can we start tomorrow?”

I like to describe Dropbox as a 2 Gig flashdrive in the Cloud. It shows up on all of my PC’s (home and office) and mobile devices (iPhone and iPad) as part of my file system. Whatever files I copy, change or remove from this drive are instantly reflected on all of my devices. I can share specific folders with friends if I choose, or keep folders private.

The best part – the first 2 Gig’s are free. More than enough for me.

Take a look: www.dropbox.com

- Frederick P. Brooks, Jr.

by Robert I. Sutton

What makes a boss great? It’s a question I’ve been researching for a while now. In June 2009, I offered some analysis in HBR on the subject, and more recently I’ve been hard at work on a book called Good Boss, Bad Boss (forthcoming in September from Business Plus).

In both cases, my approach has been to be as evidence-based as possible. That is, I avoid giving any advice that isn’t rooted in real proof of efficacy; I want to pass along the techniques and behaviors that are grounded in sound research. It seems to me that, by adopting the habits of good bosses and shunning the sins of bad bosses, anyone can do a better job overseeing the work of others.

At the same time, I’ve come to conclude that all the technique and behavior coaching in the world won’t make a boss great if that boss doesn’t also have a certain mindset.
My readings of peer-reviewed studies, plus my more idiosyncratic experience studying and consulting to managers in many settings, have led me identify some key beliefs that are held by the best bosses — and rejected, or more often simply never even thought about, by the worst bosses. Here they are, presented as a neat dozen:

1. I have a flawed and incomplete understanding of what it feels like to work for me.
2. My success — and that of my people — depends largely on being the master of obvious and mundane things, not on magical, obscure, or breakthrough ideas or methods.
3. Having ambitious and well-defined goals is important, but it is useless to think about them much. My job is to focus on the small wins that enable my people to make a little progress every day.
4. One of the most important, and most difficult, parts of my job is to strike the delicate balance between being too assertive and not assertive enough.
5. My job is to serve as a human shield, to protect my people from external intrusions, distractions, and idiocy of every stripe — and to avoid imposing my own idiocy on them as well.
6. I strive to be confident enough to convince people that I am in charge, but humble enough to realize that I am often going to be wrong.
7. I aim to fight as if I am right, and listen as if I am wrong — and to teach my people to do the same thing.
8. One of the best tests of my leadership — and my organization — is “what happens after people make a mistake?”
9. Innovation is crucial to every team and organization. So my job is to encourage my people to generate and test all kinds of new ideas. But it is also my job to help them kill off all the bad ideas we generate, and most of the good ideas, too.
10. Bad is stronger than good. It is more important to eliminate the negative than to accentuate the positive.
11. How I do things is as important as what I do.
12. Because I wield power over others, I am at great risk of acting like an insensitive jerk — and not realizing it.

WDDinc perspective: A list to make us all think. Whether a boss, spouse, parent or anyone responsible for others. Hopefully the simple act of thinking will improve our relationships.

Jay spent his time at WDDinc in the testing side of our business, working for two consecutive off-seasons as an intern.  He spent time on the CommScope, One Degree and ITT projects.  Last winter, Jay decided to focus full time on his baseball career – a decision that has paid off this week.

Congrats Jay!

Check out the news article on Jay being called up here!