Before you stop reading and get back to your _____ (insert whatever project you had planned for today), wait! You have our assurance that this won’t be too jargon-y. We’ve deliberately stopped the heavy tech talk here, and we’ll translate all the application security risk verbiage into usable, understandable terms for your growing enterprise.

So here they are, without further ado, the top five application security risks for 2010:

1) Injection Attack

All Web applications that collect and transmit data (using forms for example) are susceptible to Injection Attacks. By sending specific commands through your application’s forms, hackers can modify various elements of the code. In extreme cases, injection attacks could allow attackers to penetrate a firewalled environment such as the network environment or database.

SQL injections like the ones that compromised Symantec and NASA this year dominate this attack category, but there are many additional varieties to which you could fall prey. Impress your IT staff by nodding knowingly if he mentions a Code Injection, Command Injection, or XPATH Injection around the water cooler.

Some of the best, protective measures (ask your security expert about these) for Injection Attacks include:

• Input Validation – cleanse your input data
• Human Verification ie CAPTCHA
• Restrictive Privileges when connecting applications to DBs and other proprietary systems
• Vague Error Messages give attackers little detail to go on and can help defray an onslaught

2) Cross Site Attack

Cross site scripting (XSS) attacks steal private information like cookies or session tokens that unsuspecting users have associated with a particular Web site. XSS exploits can also redirect victims to familiar “looking” Web content that has been devised by the attacker to steal personally identifiable information or install malware.

Hackers deliver the malicious XSS-laden content that makes these exploits possible in the form of JavaScript, HTML, Flash or any executable code format for that matter. Any Web application that compiles user-generated content without validating or encoding it first could fall prey to an XSS exploit. Social media hubs and blogs that allow users to post un-moderated comments are extremely susceptible to malicious XSS exploits (as was the case with Reddit‘s Stored XSS Attack earlier this year).

Reflected XSS Exploits can be combined with phishing techniques to invade private information systems like email. Lance James and his team of experts reveal how (easily) they exploited an XSS vulnerability to win Strong Webmail’s $10,000 challenge in a quick two weeks.

Developers can help prevent XSS Attacks by deploying code that:

• Validates user input
• Does not give a site or page “full trust” simply because HTTPS is present
• Is tested. Test, test, test, and then test again before launching or introducing Web site enhancements

3) Cross Site Request Forgery – CSRF

CSRF exploits force unknowing users to carry out any number of malicious activities as long as the action is allowable within their permission set during an authenticated user session. If a Web application administrator’s credentials are compromised for example, CSRF could overtake the entire Web site.

Here’s a short list of some common (and catastrophic) CSRF capabilities:

• Force a user to post an insulting comment or malicious link on a blog or forum
• Change passwords, emails, login credentials effectively terminating access
• Submit a users email and sign up for a newsletter
• Make a purchase and use the hacker’s shipping address

CSRF capabilities are so powerful, you can understand why banks, financial brokers, bill pay services, and basically any institution that ties user credentials to money would need to approach each day with extreme caution and oversight. In a blog post this year, SECCOM Labs demonstrated how easily a CSRF banking scheme could be carried out.

Prohibiting users from submitting HTML code is one way help prevent CSRF. In many cases however, that’s not feasible because sites containing blogs and social media rely heavily on user-generated content. If your application has Social Web components, be aware that extremely effective, proprietary tools capable of disarming security features of even the most popular social vehicles like Twitter and Facebook, do exist.

Protect applications from CSRF Vulnerabilities by:

• Only accepting POST transactions
• Create unique token values for each request
• Re-authenticate based on the unique token or a password

4) Insecure Direct Object References

Insecure Direct Object Reference flaws allow attackers access to private directories (for example) by manipulating the URL to gain access. The primary risks with Insecure Direct Object References include data leakage and identity theft. Adobe Flash Player fell victim to this type of flaw last year, and the company has since addressed and patched the vulnerability.

Developers with expertise in securing applications can help prevent Insecure Direct Object References by:

• Creating a schema to protect and identify each object accessible by users
• Using indirect reference maps in code when referring to file names, URLs and DB keys
• Ensuring the session is authenticated to view the requested information or files and only grant access for that specific request when direct references are required

5) Broken Authentication and Session Management

Because all Web applications have (at least) an administrator account, each and every Web site is susceptible to authentication and session management flaws. All too often, fingers point toward typical Web site functions like logout, forgotten password retrieval, and account update procedures when problems with authentication and session management arise.

Custom applications have increased risk. In fact, many instances of authentication and session management flaws occur when code includes custom methods for validating user names and passwords and/or “home grown” techniques for handling cookies or session tokens. Session hijacking is a good example of the trouble that can crop up when authentication and session management flaws reside within your application.

Using widely accepted mechanisms for user authentication and session management is a good, preventative start. Additionally, you can take these steps to protect your application from these vulnerabilities.

• Use https:// encryption on every page with form fields and store credentials in encrypted format and limit browser caching so hitting the “back” button doesn’t grand unwanted parties access or visibility
• Make sure users can “Logout” from every page within the application and set short visitor sessions and force visitors to “time out” more often
• Limit unsuccessful login attempts and require users to verify old password credentials when establishing new ones

That’s your top five for 2010. From our company to yours – happy holidays and a hack-free New Year!

A version of this article was published in eCommerceDeveloper on 12/23/09.

Step 1 Announce and assess the breach
Step 2 Conduct a deeper investigation
Step 3 Notify affected individuals and organizations and begin remediation
Step 4 Re-launch
Step 5 Communicate the resolution publicly and to affected parties
Step 6 Take steps to remediate vulnerabilities and prevent a future breach

Today’s discussion takes a deeper look into step six, preventing cyber crime at small and medium sized businesses. The truth is that security measures in place at most SMBs are “easy pickings” for hackers, and there is a booming community of C2C (criminal to criminal) interactions focused solely on stealing customer data from SMBs that conduct business online. The same way you work every day to develop new, enticing products and easier ways for your customers to shop, cyber theft “shop owners” fuel this sub economy by devising faster, easier, and more effective methods by which to steal your company’s valuable data.

Preventing data leakage takes an ongoing, concerted effort, so it’s important that you take proactive control over your immediate environment. Here’s how:

Only run software you need. Thoroughly review all third party applications before introducing them to your environment. Only install third party applications if they are absolutely necessary. Remove all inactive programs at once. Paring down your list of installed programs alleviates your susceptibility to any known or future security threats they may pose.

Stop ignoring those updates. Install every software update, and do it quickly. Addressing security vulnerabilities is a top priority of software patches, so don’t get versions behind.

S = More Secure. Traditional FTP connections are insecure. Look for “SSH” and “SFTP” connections as they are in an encrypted format and are the minimum standard for eCommerce Web site administration.

Manage change. Terminate access credentials for former website administrators and employees immediately after (and sometimes before) they exit the company. Open logins create an extremely popular data leakage point. Implementing strict, consistent, change management protocols will reduce the chances your website is compromised by a password breach.

Check configurations and permissions. Regularly check that server configurations and file permissions are set correctly, and that there are no open permissions on directories.

Cheaply outsourced labor could cost you. Do you really want to outsource your livelihood to the lowest bidder? Websites require ongoing maintenance, bug fixes, and enhancements, and working closely with a local developer that you can meet in person might be the best solution in the long run.

Hire a hacker. Hire a hacker to try and penetrate your environment to find its vulnerabilities. I’m serious.

Achieve PCI Compliance if you conduct eCommerce. The payment Card Industry has devised a succinct list of requirements to which every organization must adhere if they accept credit cards as a form of payment.

Vulnerability audits. Have professionals perform regular vulnerability audits. We recommend monthly or quarterly (at minimum). Vulnerability audits can identify weak logins, data leakage from forms, SQL injection vulnerabilities, DDoS activity, spam relaying, order manipulation, admin control panel tampering, and more.

Hackers pose a real threat to SMBs, and they find value in stealing customer records, even from the “one-man shops” out there. Give these preventative measures the same priority as the way your site looks and works. Afterall, an ounce of prevention…well, you know the saying.

A version of this article was featured in VentureBeat on December 16, 2009.

For many ecommerce developers

For good reason. Determined hackers can compromise the most sophisticated network by combining simple, free tools with a little effort. In fact, the cyber-criminals behind the famed TJ Max and Heartland Payment Systems breaches used novice techniques like War Driving and SQL Injections to access the retailers’ networks.

If hackers can penetrate the network of a global enterprise, imagine what they can do to your clients’ small businesses. It’s a scary proposition, no doubt, but it shouldn’t keep you from going down that path when a project requires it.

Managing Credit Card Data

The first (and perhaps most important challenge) you’ll face with such an ecommerce development project is credit card collection, storage, and handling. One of the easiest and least risky options is to offload, via an API, the storage and handling of credit card numbers to a payment gateway that “hides” credit card data – Authorize.net, PayPal, BluePay or the like. If the credit card data is passed directly from the client (browser) to the gateway, without passing through your client’s web server, you’ll reduce your liability as the developer and help keep your client’s ecommerce site protected.

However, this solution many not work in all situations or for all clients for, at least, a few reasons.

1. Complicated recurring billing. If your client has a complicated recurring billing structure wherein payments vary in time, frequency, amount, or purpose; or if your client’s customers use purchase orders, your client may need to keep the raw credit card numbers available for the flexibility. Your client can still use tokens and offload the recurring billing to some credit-card-obscuring payment gateways as mentioned above, but again the need to process or manage customer data can be project specific.
2. Save on Interchange fees. All credit-card merchant-account providers charge an Interchange fee, and these fees can and do vary from provider to provider. So for some potential clients managing customer credit card data can be well worth the risk if doing so allows them to get a significantly better fee structure.
3. Offloading credit-card-storage is not enough. If credit card data passes through your client’s web server, whether the business stores that data or not, the system you develop needs to be PCI compliant. In short, whenever possible, choose a solution that never exposes your web server and your client’s ecommerce business to customer data. But when a project does call for credit data transfer or storage, you’ll need to build a Payment Card Industry compliant system that hackers cannot easily overcome.

Understanding the Requirement for PCI compliance

The Payment Card Industry (PCI) Security Standards Council has established twelve mandatory practices and precautions that must be taken when handling, processing, storing, and transmitting credit card data. The effort necessary to achieve PCI compliance will vary depending on the state of your development and hosting environment in which the ecommerce application will reside. While the specific details of becoming PCI compliant would merit a separate article, it is important to remember that when a project calls for “touching” credit card information, PCI compliance is a must. Your ecommerce client cannot do business without being compliant.

Cutting the Cost of PCI Compliance

PCI compliance can be expensive. For example, building a PCI compliant system from the ground up may require enlisting the help of a Qualified Security Assessor (QSA) to shape the scope of your PCI compliance undertaking; a number of audits; and monthly scans. All of this may cost a Level 3 merchant—those that process between 20,000–and–1,000,000 transactions each year—up to $155,000, according to the PCI DSS Compliance Blog .

The cost for smaller, Level 4 merchants, processing less than 20,000 transactions each year, varies greatly, but could cost $2,500 or more according to a payment gateway provider.

As a savvy developer, you may be able to help your client defray some of these costs.

1. Find a compliant host. Choose a web hosting environment that is already PCI compliant. If your client doesn’t need to own servers, consider a qualified, PCI compliant host.
2. Encourage processing in the client. The points above notwithstanding, choosing a solution that captures credit card data in the client, passing a token to your client’s web server, may be the best option.
3. Small merchants can do it themselves. Consider taking the “self assessment.” Level 2 and smaller merchants can self-assess rather than hiring a third-party to do the assessment, which can be a money saver.

PCI Compliance: You Need to Do It

Achieving PCI compliance is not only mandatory for all ecommerce merchants, it also assures that you and your client have taken all the steps necessary to provide a safe shopping experience for your client’s website users. Taking the steps to secure your client’s environment before a security breach may go a long way with Visa, Mastercard, the PCI Council, and forensic auditors who will be performing due diligence should disaster strike.

In fact, mitigating a security breach may be more challenging and expensive for non-compliant companies. Forrester Research estimates that mitigation will cost an average of $200 for each person/credit card account that is compromised.

This article was featured in eCommerce Developer on December 8, 2009.

Just like choke holds, Denial of Service attacks come in a variety of flavors – Flood Attacks, SYN Attacks, Smurf Attacks, Ping of Death Attacks, and the ultimate tap out producer Distributed Denial of Service Attacks (to name a few). Each method is designed to achieve a single goal – stifle the target website or online application.

Generally speaking, DoS/DDoS attacks accomplish this by directing a flood of “packets” (fake visitors, often robots) to your website at the same time. In simple terms, a denial of service attack takes up all your hosting environment’s available bandwidth and resources making it impossible for human traffic to reach your website or service.

DoS/DDoS Popularity and Severity on the Rise

Geared toward taking sites offline rather than stealing information or deceiving unknowing web surfers, DoS/DDoS attacks could be regarded as the cyber “crime of passion”. These attacks have effectively silenced religious and political groups from publicly publishing their opinions. High-profile organizations make headlines most often, but really any group with “offbeat” opinions could be the target of a DoS/DDoS onslaught.

Extortion is another popular motive behind DoS/DDoS attacks. Just recently, several Australian sports-betting websites lost millions in revenue over a busy weekend when criminals held their web services hostage for ransom money. Other commercial entities are starting to feel the effect of DoS/DDoS deployments too. Recruit Advantage and Bitbucket have both recently suffered losses due to prolonged outages, and it’s only a matter of time before mass-market retailers use attack-for-hire services to wreck holiday sales for the competition.

DoS/DDoS attacks can take a website or online service to it’s knees effectively and inexpensively, so they are growing to become a popular add on to botnet operators’ portfolios. For a mere $200/day, common Rent-a-DDoS operations can dish out botnet deployments ranging from 100Mbps to 100Gbps. Prolonged over several days, an attack of this magnitude could leave your start-up with a 5-digit invoice for bandwidth.

How to Prevent a DoS/DDoS Smackdown

Unlike other cyber crimes, this type of attack may not pose a direct threat to your clients’ PII (personally identifiable information). That doesn’t spare you the expense of lost sales, regaining public opinion, and technical resources however. In addition to those more “expected” costs, you’ll face charges for the bandwidth consumed during the exploit, and that bill alone could be enough to lead your startup business to early retirement.

The worst part is that if a cyber opponent has you in his or her sights, you’re going down for the count. There are no known prevention methods on record. DoS/DDoS attacks are like a jump spinning rear kick delivered in your blindspot. Scary, deadly stuff.

Don’t Take DoS/DDoS Exploits Lying Down

Since you can’t “eat healthy and excise” your way out of a DoS/DDoS attack, your best bet is to position your website or online application to mitigate the incident. Do this by monitoring your traffic and system state closely at all times. Knowing traffic trends gives you the best chance for getting your guard up FAST, so you have a chance at successfully mitigating the attack.

No matter what equipment or techniques are deployed to mitigate a DDoS/DoS attack, if your internet connection is smaller than the attack size – you’re down. For example, if you have a 100Mbps connection to the internet and the attack is 400Mbps (typical attack size), then the attack exceeds your available bandwidth by 4x saturating your entire network rendering services incapable of responding.

However, if you have enough bandwidth capacity available these techniques and devices are good allies to have when you’re immersed in the heat of a denial of service battle:

• Traffic Redirection – Deny all traffic, good and bad. This method is effective for getting your resource consumption under control and restoring order to your server, but it does not solve the problem of getting customers back in your virtual door.
• IP Filtering – Using routers or firewalls to filter traffic by geography for example can be an effective way to deny traffic from IPs based outside your service area – the US for example. Unfortunately, these devices can only sniff invalid IPs; they are not effective when spoofed or valid IPs are attacking.
• Intrusion Prevention Systems / Application Firewalls – These expensive and adaptable devices “learn” your traffic and can help deny access from malicious origins very effectively.
• DoS Mitigation Appliances – Specialized hardware and software made specifically to fight DoS attacks, DoS/DDoS mitigation appliances provide functionality similar to IPSs and WAFs. This appliance should sit on the very edge of your network (outside your firewall) so it’s taking the attack load off your network.
• Application Optimization – Expertly configured applications can help mitigate D0S/DDoS incidents or an influx of desirable traffic for that matter. Caching pages, for example, can help defray the impact of an attack.
• Load Balancing / Clustering – Servers can handle a substantial amount of traffic (both good and bad), so load balanced / clustered environments provide diversification and help prevent a bottleneck within a single piece of hardware.

If you’re attacked by a DoS/DDoS exploit, your network will consume bandwidth at a high rate for a sustained period of time, so review and understand your billing agreement for bandwidth overage. The alternative, limiting your bandwidth pipe will help prevent the unexpected bill, but again it doesn’t get you back online for business.

If you find yourself under attack by DoS/DDoS, use social platforms like Twitter and Facebook to communicate updates with your customers and other interested parties. Customers and prospective business partners appreciate being notified as soon as possible. Plus, being the first to report the attack lets you control the message and keeps any rumors at bay.

Just as your head tips back and your mind wanders off to dream about the great momentum strong holiday sales will provide for your new enterprise, the phone rings. It’s your Web site developer. The news is not good. Somehow, someone has compromised your site’s customer database and taken critical customer data, like credit card information.

What you do in the next 48 hours will be critical to getting your business back online, on track, and on safe ground. Two things to remember: Transparency and Communication. It’s not just about restoring your Web site to a secure state but restoring your customer’s confidence to continue to shop with you.

Step 1: Announce and Assess (Timeframe: Immediately – 12 hours after the breach is discovered)

Immediately, get your site offline. Google has some specific recommendations regarding the best way to accomplish this.

Customers appreciate being notified as soon as possible, and they would rather hear it from you first. Plus, being the first to report the cyber crime lets you control the message. Concurrently, make a general public statement about what has happened and instruct all individuals (or companies) who have done business with your company to monitor their credit report and banking statements for inconsistencies.

Deliver the statement to all concerned parties via email and make sure to train all customer-facing representatives with the appropriate dialogue. Here’s a concise and effective example from Balmar Incorporated.

Step 2: Conduct a Deeper Investigation (Timeframe: 12 hours – 36 hours+)

Computer forensic auditors, PCI representatives, governmental agencies, and others may be involved in the process depending on the nature of your business.

Start by interviewing all personnel responsible for securing your environment and find out if they are aware of any known vulnerabilities. Next, begin reviewing log files with the following specific goals in mind: Identifying the date(s) of the breach, how many customers were compromised, and what information was stolen.

Step 3: Notifications and Remediation (Timeframe: 36 hours – 48 hours or as soon as you’ve pinpointed the problem)

Contact the police, FBI, and Attorney General with all the details you’ve compiled about the situation. This may sound severe, but forty-five states have enacted legislature that dictates who should be notified, and how, when PII (personally identifiable information) is leaked, and these governmental agencies will direct you on what information to divulge and what to keep private for their investigation. Government agencies are taking cybercrime very seriously these days. They want to help businesses curtail these events so don’t feel silly bringing in the agents.

Concurrently, start technically remediating the breach. The exact steps you take will depend on the nature of the compromise, however these general rules of thumb almost always apply.

• Remove customer data from the compromised area of the database and move it to a separate, secure location.
• Back up your site, database and all log files. If possible, backup your entire server including all operating system files. This help forensics determine the breach.
• Perform a complete reinstall of the OS and your Web applications, and make sure to use the most updated software versions available.
• Reintroduce your Web site files to the hosting environment using a clean backup, free of any hacked content. Keep in mind, the only way to be 100 percent sure all affected code, links, comments, etc have been removed is to rebuild the site from scratch. If speed is of the essence, restore from an encrypted site version saved prior to the breach.
• Change your password scheme. Believe it. Most hacks result from weak or conspicuous user logins and password credentials, so start fresh with a new scheme and separate logins for each service – FTP, control panel, software admin, email.
• Run third-party vulnerability scans on your site. WhiteHat Security offers a SaaS solution that will uncover vulnerabilities that need to be shored up before re-launching your site.

Step 4: Re-launch

When you’re confident the site is secure and all vulnerabilities have been patched, launch and resubmit your site to search engines in the appropriate way so it’s crawled again ASAP.

Step 5: Communicate

You’ve worked so hard to get your site secure and back online. It’s now time to tell your customers the efforts taken to ensure the security of their information is your number one priority. Not only do you need to honestly and transparently communicate the breach but confidently affirm that their information is protected to the best of your abilities. This final communication is what determines if your customers are going to ever buy from you again.

Step 6: Prevention and “The Aftermath”

Even after your Web site is back online and business has returned to normal, your work is not done.

You’ll be facing fines, payment card industry (PCI) probation, forensic audits, and remediation. It’s not uncommon for even the smallest of businesses to rack up five or six digit expenses between penalties and legal fees. Forrester Research estimates that mitigation will cost an average of $200 for each person/credit card account that is compromised.

In reality, the unanticipated financial expense and “negative time” invested in remediating a security breach (especially during peak selling period like the holidays) could be enough to squelch your start-ups chance of ever becoming a successful medium-size or large enterprise. That’s why it’s extremely important to focus your limited and precious resources wisely.

As with your many other start up costs, protecting your Web site may seem like a hefty cost up front, but if it’s where you do business, it could save you an arm and a leg down the road. Get your site prepared for the worst-case scenario, so this holiday you can finally take that nap.

A version of this article was featured in Venture Beat’s Entrepreneur Corner on November 25, 2009.