Security PS

WASSEC is Released

2009-10-08T12:32:00.000-07:00

Version 1 of WASSEC (Web Application Security Scanner Evaluation Criteria) is (finally) out! I'm not going to say which section I wrote, but the document is (as far as I know) the first attempt to comprehensively list the features that should be considered when evaluating appsec scanning tools. Check it out. It's worth a read.

The WASSEC document be found here in both wiki and PDF formats:
http://projects.webappsec.org/Web-Application-Security-Scanner-Evaluation-Criteria

Press Release: Security PS Expands to Austin

2009-08-31T09:29:00.000-07:00

Security PS has continued to pursue plans for growth in 2009 by expanding and strengthening their presence in the Midwest and Southern regions in the US. As key part of this plan, Security PS announced the creation of a local presence in Austin, TX.

"While we do business across the US, our clients continue to place a high value on our local presence as they partner with us for application security services." commented Kris Drent, President and CEO of the firm. "This expansion allows us to provide that level of partnership with business in Austin and in the surrounding areas." he concluded.

Heading up the firm's Austin expansion is manager and consulting veteran Tom Stripling. According to Drent, Stripling's accomplishments and business knowledge made him the perfect team member to spearhead and manage the new location.

While Stripling will continue to serve key clients in the Midwest, his relocation to Austin has enabled him to take a more active role in the regional market. "Given the level of technology in this area, there is a significant need for experienced application security services here. I'm excited that we can be provide a local presence to clients in Austin and better support this region." Stripling said.

In conjunction with the expansion, Security PS continues to expand their reach in the Midwest from their headquarters in the Kansas City area and announcing new application services designed to meet emerging needs.

[ View the original press release from the Security PS website: Security PS Announces Expansion To Austin ]

Mozilla to release Content Security Policy

2009-08-17T15:46:00.000-07:00

Robert Hansen (RSnake) and others have been working with Mozilla for years to develop a working solution to the problem of user-submitted active content. Well, they're finally close to a solution. Mozilla is releasing their Content Security Policy in version 3.6 of Firefox, which will help to "prevent the creation of JavaScript code from potentially tainted strings", among other things. Basically, this means that if you're a site like eBay that wants to allow users to enter certain "safe" HTML, but not run scripts, you will be able to use Mozilla's Content Security Policy to help ensure that (at least in Firefox).

I sincerely hope other browser vendors follow suit. If this type of thing can become the standard, it will provide a powerful tool for interactive, customizable sites to protect their users.

CSRF Tokens

2009-08-17T15:41:00.000-07:00

One of the many interesting discussions at Defcon recently was a discussion of CSRF by Mike Bailey and Russ McRee. They talked about a variety of real-world CSRF attacks and pointed out that a lot of companies simply accept CSRF vulnerabilities because they don't understand the risks they pose. To help people prevent this attack, frameworks like ESAPI have implemented CSRF token generators that produce a long random value to be included as a hidden field in each sensitive form. This value is then checked when the form is submitted, preventing attacks like CSRF from working.

While I was reading about this, I came across an interesting attack against CSRF tokens that was published last month. It's a cool idea. He uses the CSS properties of the browser's history to brute force token values. This works a little better than previous techniques because it generates no traffic to the server and likely isn't detectable by server-side defenses.

As other authors have already pointed out, this doesn't doom CSRF tokens to uselessness. They're still the most effective defense against CSRF attacks as long as they have a sufficient key space to prevent brute force attacks. Just make sure you use a long random value for your CSRF tokens and you'll be fine.

A Quick View State Review

2009-08-05T15:14:00.000-07:00

It's been seven years now since the release of the first .NET framework. Throughout all that time there are few aspects of the framework that have been continually misunderstood like the View State. It's a common thread throughout many of the ASP.NET applications that I assess; the View State is misused a lot.

View State misuse leads to a few different problems. Bloat is a common one, and so is accidental disclosure of sensitive data. Every once in a while I'll even see an application with the View State message authentication code (MAC) disabled, allowing attackers to manipulate the View State's values. Of course, the problems with information disclosure and manipulation can be easily solved by turning on View State encryption (and hopefully, setting the ViewStateUserKey* as well). But that's not really addressing the problem at its source.

These problems seem to arise from a basic misunderstanding of the purpose and function of the View State. The standard statement that everyone hears about the View State is that it persists state across postbacks. This simply means that programmatic changes to the properties of any controls will be stored and persisted in the View State across postbacks. Changes to the default properties that are made declaratively or before the control is added to the page's control hierarchy will not be tracked. This means that, ideally, control properties should be set in the ASP code itself instead of in the code-behind file. That way, they won't have a chance to pollute the View State.

This is a pretty key idea and the following two articles, by Scott Mitchell and Dave Reed, respectively, should be required reading for understanding the whole concept.

Both of these articles describe what the View State really is, and more importantly, what it isn't. Applying the information presented in the articles above will go a long way towards reducing security problems with the View State. However, in the cases where sensitive data is still leaking, it may be easier to not use the View State at all. In many cases, it can be completely turned off without impacting the functionality of the application. In other cases, the View State can be disabled on a per-control basis. More good news on this front is that ASP.NET 4.0 will give developers more control over exactly how the View State is used on a page.

* Setting the ViewStateUserKey can help protect against POST-based cross-site request forgery (XSRF) or one-click attacks. However, in order for the ViewStateUserKey to work, the View State MAC must be enabled. Depending on the application, this feature alone may be worth leaving the View State enabled. More information on the ViewStateUserKey property can be found at the following site:

http://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic2

Defcon Wrapup

2009-08-03T15:36:00.001-07:00

The team has returned from Defcon unscathed. Well, maybe only slightly scathed. We caught several really great presentations. Watch this space for summaries of our favorites. The conference was not without its usual hacker stupidity, though. Some highlights:

A fake ATM was found in the lobby of the hotel and quickly carted away. There are claims that this was the work of credit card scammers not affiliated with the conference. If so, it was very poorly timed.
Someone attempted to bungee jump from the roof of the Riviera. He was stopped by hotel staff before he was stopped somewhat more abruptly by the wall of the building.
One person decided to try to hack an elevator and got himself and 14 other people stuck for an hour.
And a large number of people connected to the wireless network and logged in somewhere. Or brought something to the conference with an RFID tag in it. Or left Bluetooth enabled on their phone. All of them ended up on the Wall of Sheep.

Security PS On Twitter

2009-06-10T08:24:00.000-07:00

For all you Twitter fans out there, you can check out what we're up to at Security PS by following us on Twitter:

http://twitter.com/SecurityPS

DeMystifying CFINSERT SQL Injection

2009-05-29T14:09:00.000-07:00

Not much has been said as to the security of Adobe ColdFusion cfinsert and cfupdate tags. These functions transform input from a POST request into a database insert or update query. Essentially, a developer specifies a database table and creates a form field on a page. When a user submits those values, ColdFusion automatically creates a query to insert or update the corresponding values in the database. In essence, these tags give the developer the ability to execute SQL without writing SQL.

Looking through information available online and through Adobe, it is mentioned that these functions are vulnerable to SQL injection but there is no mention as to how. The majority of discussion pertaining to this potential security issue stopped abruptly around 2007. Even an article written by the 0x000000 hacker webzine in the summer of 2008 about ColdFusion security did not mention cfinsert or cfupdate vulnerabilities.

After looking in to the documentation of these tags, something just did not sit right. As a programmer, I generally desire very fine grained control over the flow of computation. As a security consultant, I generally fear an application which “writes the code for you.” It is very difficult for an application framework to draw the line between robust and secure.

Overview

For practical reasons, I decided to only look at cfinsert’s behavior with regards to Microsoft SQL Server 2000. The test lab consisted of two virtualized Microsoft Windows 2003 Server machines. One machine ran Microsoft IIS 6.0 with ColdFusion 8.x. The other machine ran Microsoft SQL Server. The reason for the breakout is Microsoft Windows does not take kindly to packet sniffing across loopback interfaces.

The general approach taken was to observe database commands sent from ColdFusion to SQL Server under three basic query scenarios. The scenarios identified were a regular (vulnerable) query, a parameterized query, and a cfinsert query. The first two queries where chosen to serve as a baseline against the potentially vulnerable cfinsert query. The tools used included Wireshark and the Microsoft TRACE tool, available as part of SQL Server. In the interest of simplicity, the database has no primary keys or relationships defined. Below are the observations of these commands.

The Results

Standard query with no protection

As expected, the standard ColdFusion cfquery function offers no protection from injection vulnerabilities. The TDS packet (RPC packet for SQL Server databases) sent inserted the user controlled parameters verbatim in to the SQL query allowing injection.

Standard query with parameterized values

The first time a parameterized statement is run after a ColdFusion server reboot, it will make use of the sp_prepexec command to dynamically create and execute a parameterized SQL statement in Microsoft SQL Server. Subsequent calls make use of the sp_execute command. User input is properly separated from the SQL logic. Therefore, typical SQL injection attacks are not possible.

cfinsert

This is the case that is of most interest to us and also the most complicated. The cfinsert (and cfupdate) statements work in the same way as the parameterized queries with one additional step. Before a call to either sp_prepexec or sp_execute is made, the sp_columns prepared statement is called.

The first statement executed is sp_columns N’tmptable’, NULL, NULL, N’%’, @ODBCVer = 3. One can only assume that ColdFusion is verifying names of the POST variables align with the column names in the table. By adding or modifying the names of POST variables to nonexistent columns, a call to the cfinsert query fails.

Conclusion

To answer the original question, there is no black and white answer as to whether cfupdate or cfinsert are injectable. If the application is not coded to strictly validate the POST data before use in cfinsert queries, you can add information to other columns the original developer never intended. Although this is not as severe as a more traditional SQL injection attack, depending on the data modified, this can still introduce a large amount of risk to the application. For example, when creating a new user and adding to an authentication table, I can specify additional fields and arbitrary information in the POST request that modify my account type or permissions.

Recommendations

My recommendation is to rewrite your cfinsert and cfupdate statements to use parameterized queries or prepared statements. Even if there are no columns for which a user should not be able to access at the moment, there is no guarantee that a database change will not introduce problems in the future. Futhermore, this allows the developer to introduce integrity checks which is a cornerstone of a good application security strategy. If this is not an option, Adobe ColdFusion also supplies a method to specify a whitelist of form fields to allow. This is essentially a requirement for using cfinsert of cfupdate securely. An example of using specifying a cfinsert whitelist is shown below:

Microsoft !exploitable Crash Analyzer

2009-04-28T14:22:00.000-07:00

Recently at CanSecWest 2009, Microsoft released their internal !exploitable Crash Analyzer to the general public using their Microsoft Public License (Ms-PL). This tool plugs in to the Windows debugging extension (Windbg) and attempts to both uniquely identify and assign an “exploitability” rating to program crashes. Essentially, the end goal of !exploitable is to group crashes by location in code and classify them by severity. Both the CanSecWest presentation and tool can be found on the Microsoft CodePlex website at: http://msecdbg.codeplex.com.

Where will this be used?

An effective bug and vulnerability management program is one sign of a mature and security-aware product program. In a perfect world, resources will be unlimited, developers will always have time to go through all the proper security training, every line of code will be peer reviewed, there will be time to properly validate both the design and implementation before release, products will scale well as new features are added, and there will be plenty of time to perform a full application security assessment and remediate any issues identified. In reality, security vulnerabilities do happen. Furthermore, they are not always easily segregated from other bugs (especially in the finite amount of time dedicated to remediation). By classifying program crashes as Exploitable, Probably Exploitable, Probably Not Exploitable, or Unknown; this tool aims to help organizations triage their bug reports. These ratings tie in directly to the Microsoft Exploitability Index now included with security bulletins. More information about this index can be found on Microsoft Technet at: http://technet.microsoft.com/en-us/security/cc998259.aspx.

How does it perform?

After reading about this tool, I was curious as to how well it performs. I ran a couple of binaries through the tool that were compiled using MinGW (GCC for Windows). The binaries with buffer overflow and format string vulnerabilities had stack protections disabled. The following GCC compilation options were used to disable stack protections:

-fno-pie -fno-stack-limit

Buffer Overflow, No Stack Protection, MinGW
A stack based buffer overflow is a condition that arises when a program is allowed to store data beyond the bounds of the pre-allocated memory space reserved. In this situation, the data will overwrite other values on the program stack. Typically, an attacker will leverage this vulnerability to control program flow by modifying local variables, function pointers, or the return address of the stack frame.

The following excerpt is the vulnerable code from the application used to force a program crash from a buffer overflow condition.

char buf[8];
if(argc>1)
strcpy(buf, argv[1]);

The following is the rating and information outputted by the Microsoft !exploitability tool.

Description: Read Access Violation at the Instruction Pointer
Short Description: ReadAVonIP
Exploitability Classification: EXPLOITABLE
Recommended Bug Title: Exploitable - Read Access Violation at the Instruction Pointer starting at Unknown Symbol @ 0xa3e1dcffff000a (Hash=0x264d5172.0x1e004834)

Format String, No Stack Protection, MinGW
A format string vulnerability arises when a program uses unfiltered input in the format specifier of certain formatted output functions such as printf, fprintf, or scanf. An attacker can supply his or her own formats to write an arbitrary value to an arbitrary location. Many attacks involve an attacker overwriting a function pointer to control program flow. The following excerpt is the vulnerable code from the application used to force a crash-dump from a format string vulnerability.

The following excerpt is the vulnerable code from the application used to force a program crash using format string specifiers.

if(argc >1)
printf(argv[1]);

The following is the rating and information outputted by the Microsoft !exploitability tool.

Description: Read Access Violation
Short Description: ReadAV
Exploitability Classification: UNKNOWN
Recommended Bug Title: Read Access Violation starting at image00400000+0x1327 (Hash=0x575c4810.0x70226436)

Function Pointer Manipulation, Default Stack Protection Enabled, MinGW
I compiled a program where a user can directly control the pointer to a function. An attacker would leverage this overwrite the funptr to point to the address of his or her shellcode thereby executing arbitrary instructions on the machine. This was compiled using the standard GCC flags to enable stack protection. The rating of this is interesting in that it changes based on the address of the function pointer. Moving the function pointer a small difference (one) elicits a Probably Exploitable rating. Moving the function pointer a larger difference (ten) elicits an Exploitable rating.

The following excerpt shows a vulnerable program moving the function pointer to a user supplied location.

int (*funptr) (void) = &function;
if(argc >1)
funptr += atoi(argv[1]);
result = (*funptr)();

Adding one to the function pointer will elicit the following rating.

Description: User Mode Write AV near NULL
Short Description: WriteAV
Exploitability Classification: PROBABLY_EXPLOITABLE
Recommended Bug Title: Probably Exploitable - User Mode Write AV near NULL starting at Unknown Symbol @ 0xa3e1dcffff000a (Hash=0xd667a59.0x9444d1e)

Adding ten to the function pointer will elicit the following rating.

Description: User Mode Write AV
Short Description: WriteAV
Exploitability Classification: EXPLOITABLE
Recommended Bug Title: Exploitable - User Mode Write AV
starting at image00400000+0x12ea (Hash=0x575c4810.0x70226436)

Conclusion

It is important to note that this tool relies on analyzing program crashes to generate a rating. By that definition alone, there is a huge range of attack vectors that will not be covered. Not every vulnerability will crash a program, and for this reason, !exploitable can never be looked at as a “find all tool.” Of the conditions that !exploitable can analyze, it did not accurately identify the format string vulnerability. This worries me as I am now concerned as to what other severe problems it may miss.

With these limitations in mind, I would treat the !exploitable tool as a guide to raise the awareness of those vulnerabilities that are exploitable. I would not rely solely on this tool to categorize or assign risk ratings to program crashes. As long as one only relies on this tool to move a small selection of vulnerabilities to the top of the list, it can be a great asset to an organization. Hopefully, Microsoft will continue to invest in this tool as it has the potential to become a good weapon in a security organization’s arsenal.

Resources

http://www.snoop-security.com/blog/?tag=exploit-development
This is the blog post which inspired me to look in to this myself. This particular article goes much more in depth as to how different protections (such as Microsoft DEP and GS) affect the ratings.

http://msecdbg.codeplex.com
!exploitable Crash Analyzer homepage on Microsoft CodePlex

http://www.microsoft.com/security/msec/default.mspx
Microsoft Security Engineering Center homepage

Security PS Adds Team Members In Kansas City

2009-04-20T16:13:00.000-07:00

Continuing with more news of growth and expansion, we've added a small army of new team members in the Kansas City location. Welcome to the team Naithan, Amy, Mike, and James!

Press release: Security PS Adds Team Members In Kansas City

Security PS: Strong Direction for 2009

2009-04-19T11:37:00.000-07:00

The first quarter of 2009 has been busy here at Security PS. We've made a lot of progress towards growing and laying the groundwork for a number of new opportunities. We've posted a press release to tell you more about it, but here's a quick summary:

Partner buyout paves the way for new initiatives
Growing headcount
Deepening of application security offerings
Adding a new Security PS location soon

Press Release: Security PS Sets Strong Direction for 2009

Google Client Redirection Vulnerability

2009-04-14T12:00:00.000-07:00

As a part of its search functionality, Google creates redirection links that send users to other sites on the Internet. Although the search engine giant has some simple measures in place that attempt to prevent tampering with these links, it's possible to create URLs that appear to go to www.google.com, but actually send a user to an arbitrary site on the Internet. Consider this example (link will probably no longer work):

http://www.google.com/url?q=http://3mu.us/ts/google.html&ei=a97kScyaK46eM4DivLwP&sa=X&oi=unauthorizedredirect&ct=targetlink&ust=1239737715710481&usg=AFQjCNHVIkLAF91Rr7PU28ag6FTR4ZZvsg

That link starts with www.google.com, but (if you had clicked on it within the first few minutes after it was created) it would actually take you to
http://3mu.us/ts/google.html, which is a page I constructed to look exactly like the iGoogle login page. (Don't worry, it doesn't actually capture any information… but it could!)

Although Google would have a hard time preventing me from trying a phishing attack on their users, allowing me to use their own domain as the phishing URL helps increase the potency of my attack tremendously. Basically, they are letting me use their users' trust in the google.com domain against them.

Their mitigation strategy appears to be that they set a timeout on the link (which is why the above example probably won't work). Of course, the most common phishing attacks are propagated through email. Users who are sitting at their computers when they receive an email warning them of a "serious problem with their iGoogle account" might be enticed to log in immediately to check it out.

This vulnerability is obvious enough that I'm betting I'm not the first one to find and report it, but I notified Google just the same. I'll post an update when I have their response.

Twitter XSS/XSRF Worm

2009-04-13T13:52:00.000-07:00

Over the weekend, Twitter was attacked by a JavaScript-based worm that spreads by using a cross-site request forgery (XSRF) attack to update the twitter status of anyone who viewed an infected profile. The update included obfuscated JavaScript that spread the attack (unobfuscated version).

A 17 year old has admitted to creating the attack to promote his website (and out of boredom). While his site will undoubtedly get more traffic, I wouldn't be surprised if he also gets a felony charge for his trouble. Twitter has an explanation of the event and several blogs have an explanation of the offending JavaScript.

Google Gadget Login Forms = Not Good

2009-04-13T09:51:00.000-07:00

If you're not familiar with iGoogle (www.google.com/ig), it's a Google service that allows you to create customizable home pages by including gadgets that were contributed by the user community. These gadgets do anything from display the weather to providing news or stock reports. There are even mini Flash games you can play.

This seems harmless enough, but Google's gadget security model gave user-created (and therefore untrusted) gadgets access to your data at Google like gmail, Google docs, etc. I brought up some concerns with this model at the OWASP conference in San Jose a few years ago. Since then, Google has updated their security model to remove some of the more blatant weaknesses.

Recently, I came across a particular gadget created by the user community. It provides a login form that looks like this:

This gadget uses JavaScript to open an iframe to the eTrade mobile login form:


function display() {
  var destination_url = "https://wireless.etrade.com/etrade";
  var html = '<iframe id="iframed_iframe_id" name="iframed_iframe" 
    border="0" src="%27%20+%20destination_url%20+%20%27" 
    marginwidth="0" marginheight="0" width="100%" frameborder="0" 
    height="' + _gadget_height_pref + 'px"></iframe>';
...

So, users of this gadget are allowing their login form for eTrade to be controlled by some random bozo on the Internet. The author of this gadget could update it at any time to change https://wireless.etrade.com/etrade to https://reallyevilphishingsite.com/etrade and the user wouldn't notice a thing.

Now, is it really Google's responsibility to prevent users from using gadgets like this? I say it is. Phishing attacks come down to an issue of education and trust. A user that knows to check the location bar of their browser, look for the lock icon, and so on may still fall for a phishing attack that comes from Google. After all, the location bar says "https://www.google.com/ig", the certificate is correct, and the lock icon is right where it should be. If Google wants to host user-provided content, they should prevent gadget writers from abusing users' trust in the Google name.

OWASP Access Controls Presentation

2009-03-20T12:54:00.001-07:00

A few weeks ago I gave a presentation at our local OWASP chapter on the current state of access controls. We see access control problems to some extent in nearly every application we assess. They're hard to get right, and they're hard to detect when you've done them wrong. The talk was aimed at exposing why so many developers have a hard time getting them right, and what it takes to avoid problems with them in the first place.

The biggest trick with implementing proper access controls is that they must be done consistently and systemically. There's no room for an ad hoc approach here; the larger an application gets, the harder it is to track where each one-off check has to go. A much better approach is to generalize and standardize the checks as a single global framework.

This problem is compounded by the inability of application security scanners to accurately detect access control problems. They're simply not designed for it. Automated scans absolutely have their place in a secure development cycle, but they're not going to find your authorization problems. For this, you need manual testing and code review.

We've posted the slides used for the presentation on our site. If you're interested in seeing more, I encourage you to check them out.

Access Control Presentation Slides (PDF)

ISSA Kansas City

2009-03-06T14:58:00.000-08:00

After a very close election (in which I ran uncontested), I have been re-elected as President of the Kansas City Chapter of ISSA. If you're not familiar with the ISSA, our goal is to provide a forum for like-minded security professionals to interact, network, and share ideas.

Our chapter hosts a lunch meeting every month with a speaker from the information security industry. The topics are different each month and they range from detailed technical presentations to enterprise risk management strategies. Read more about the chapter and upcoming events at http://issa-kc.org.

Collegiate Cyber Defense Competition

2009-02-27T07:10:00.001-08:00

The consulting team headed up to Iowa State for the national Cyber Defense Competition last weekend. It's a pretty cool idea. There are two main teams: the Blue team, comprised of students from different universities, and the Red team, made up of professional hackers (like us).

The Blue team gets some time to build and secure a network of servers. The day of the event, the Red team shows up and starts to break in. Aside from being extremely fun for everyone involved, this is a great way to introduce students to practical matters in information security. They did surprisingly well, but just like in the real world, a single small error often led to a much larger compromise.

I was working on a team that had locked down their web server fairly well, but had misconfigured a single permission setting, allowing me to read a file out of their web root. I chose a configuration file for one of the web applications they were hosting, which contained the username and password to the database. I logged into the database and replaced the password hash to the Administrator account for that application. I could then log into the application and use the administration features to write files to the server and compromise it further.

Overall, I was impressed by the ways the students found to secure their systems in the face of an onslaught of professional hackers. The real world is a lot more complex, but they're certainly getting a good head start into the security industry.

The Return of the Blog

2009-02-25T14:54:00.001-08:00

To say we've fallen behind on posting to the Security PS blog might be understating it a bit. The demands of a growing company have unfortunately pushed it to the back burner. Well, we're going to change that. Look for a lot more activity in this space over the coming weeks as we talk about all the projects, research, and cool ideas our consultants have been working on.

We also take requests. If you're interested in hearing more about a particular topic, let us know.

Perl.com Hacked via Third Party JavaScript

2008-01-28T11:03:00.000-08:00

For a short while recently, if you visited Perl.com, you were redirected to a porn site by malicious JavaScript. How did the JavaScript get there? Advertising. You can read a write-up of the incident at Oreilly.com.

In short, the site at Perl.com included JavaScript on the page that was hosted by one of their advertisers on a remote system. The advertiser allowed their domain to lapse and a pornographer bought it and changed the JavaScript. This is exactly the problem that I pointed out in my talk at the 2007 OWASP conference. If you’re allowing an advertiser, a site tracking service, or anyone else to run third-party JavaScript on any of your pages, you might as well send them all of your users’ data now because they can certainly steal it if they wanted to.

Many people choose not to worry about this problem because it seems unlikely to hurt them. This attacker took a lot of time and effort to do exactly that, including examining what third party JavaScript was running on the site, monitoring site expirations to take control of the advertiser’s domain, and creating his own version of the JavaScript files to do what he wanted.

You may trust your advertising partner not to maliciously attack you, but it’s important to keep in mind that the security of your users’ data is now dependent on the security of their server/domain/data as well. You take a lot of care to protect yourself. How can you be sure that they’re doing the same?

Recommendations for some ways to reduce the risks associated with third party active content can be found in my presentation via the link above.

The Night Before Xssmas

2007-12-27T12:02:00.000-08:00

Twas the night before Xssmas and all through world
Not an application was safe, no one dared click a URL.
People’s browsers sat idle and they all pondered when
It’d be safe to view greeting cards online again.

The hackers were nestled all snug in their beds,
While visions of session cookies danced in their heads.
Developers were still working to push out new code,
But soon it’d be compromised for another bot node.

Cries for help on the Internet rose to such a clatter,
That consultants at Security PS looked into the matter.
They raced to their keyboards and started to type,
“Validate data” they cried, yet many thought it hype.

A few implemented black lists for input inspection,
And found they still fell victim to SQL injection.
The clueless were left in their server rooms gawking,
As exploits were launched that left their servers talking.

The good consultants didn’t give up in spite of all this,
And created security classes taught by a bright geek named Kris.
He showed people hacking demos and watched faces fall,
When they saw they couldn’t trust client data at all.

“Your users aren’t safe,” he said, “when it is revealed,”
“I can push JavaScript into this not-so-hidden field.”
“Plus parameters are bad,” he added with a wink,
“When they can be used to create an unsafe link.”

With time a few companies began to see the light,
And changed security practices to fix their code right.
“It’s not so hard,” they said, “when you know what to do.”
“Plus it’s nice not to have Russian hackers chatting with you.”

While we don’t want to claim victory too prematurely,
We do think more applications are being developed securely.
For those still struggling to deal with the injection plight,
We say “Merry Xssmas to you, keep up the good fight!”

Defcon 15: "Strong" Authentication in Web Applications

2007-08-28T12:10:00.001-07:00

Has your organization recently implemented multi-factor, risk-based, or mutual authentication? Do you think your application is now more secure and has a "strong" authentication system in place? Often, web applications are actually at more risk once these authentication features are introduced due to the considerable amount of complexity added. The typical result is to have implementation flaws that allow attackers to harvest usernames, obtain customers' mutual authentication images, or bypass security questions.

Until recently, there have not been many resources made available to the public about how to find and exploit vulnerabilities pertaining to these new authentication features; however Brendan O'Connor's presentation at Defcon 15 provided a great deal of visibility to these issues. His presentation, "Defeating Strong Authentication in Web Applications", discussed the common issues seen in these authentication systems and how to carry out associated attacks. O'Connor's presentation specifically discussed problems with mutual authentication, device fingerprinting, out of band authentication, one time passwords, and knowledge base archives. He highlighted technical flaws in the implementation of these features as well as reasons why the features may be inappropriate solutions to the problem an organization is trying to address.

A great example of how new risk is introduced by implementing these authentication systems can be found in the first step of many mutual authentication login processes. In the past, applications asked for the customer's username and password on a single page. If either of these credential pieces was incorrect, the application would respond with a generic authentication error which did not reveal whether the username or password was the incorrect piece.

Now that mutual authentication has been included in the mix, applications commonly ask for the customer's username ONLY as a first step. If that username does not exist, the application may display an error or behave in a completely different manner than if the username were valid. This is all happens before the application ever asks for a password, an answer to a security question, or a permanent cookie/flash object.

The added risk to the application is that an attacker can now discover one of the three secret credential pieces (for example: username, security question answer/permanent cookie, and password) needed to gain entry into the application. This reduces the "strong" authentication system's effectiveness to that of the simple username and password combination, in that only two credential pieces are needed to login.

So, is this a big deal? Do you think any hackers will test your organization's authentication system? There were around 7,000 attendees at this year's Defcon and all these attendees received a copy of O'Connor's slides. In addition, there were more than three hundred interested individuals who attended his presentation. Odds are there are many people who not only think this is a big deal, but are interested in whether your organization implemented their new "strong" authentication system securely. There are also many who may have the knowledge and expertise to find out for themselves if your web application has any of the flaws discussed in O'Connor's presentation.

My suggestion is if you haven't yet looked into these issues in your environment, you should start as soon as possible. Otherwise, someone else is going to find these authentication vulnerabilities and use them to compromise your customers' accounts.

To learn more about challenges and flaws introduced by implementing risk-based, multi-factor, or mutual authentication systems see the App Security Advisor Multi-Factor and Risk-Based Authentication podcast.

What OWASP is and what it means to you

2007-08-23T08:44:00.000-07:00

Our blog has featured a link to the OWASP web site for most of its existence. Maybe you have clicked on it and checked out the great resources that OWASP has to offer. Maybe you already know about the organization and its ongoing projects. If you aren't familiar with OWASP, let me give you a quick introduction.

The Open Web Application Security Project (OWASP) is a not-for-profit group dedicated to improving the security of web applications. They support this goal by publishing security testing and software development guidance, creating web application security testing tools, and funding related projects that benefit the community.

OWASP also encourages the creation of local chapters where security professionals and developers can meet with their peers to exchange information. These chapter meetings typically include one or more presentations covering topics like web app attacks, security testing techniques and tools, secure coding practices, and product evaluations. Meetings also serve as a good opportunity to compare notes with other locals on what is going on with web app security in their organizations.

I recently had the honor of assuming leadership of the Kansas City OWASP chapter and am excited about the chance to spread knowledge of web application security in our area. However, I can’t accomplish this goal without your help. Right now our chapter mailing list only includes a few dozen of the hundreds of Kansas City professionals who would probably want to participate in this group.

If you or others in your organization aren’t currently subscribed, I encourage you to join today. If you have friends or former coworkers at other businesses, let them know about the chapter. Subscribing to our mailing list will keep you informed about the interesting topics that will be covered at upcoming meetings.

Our next meeting is September 6th and features a presentation from a federal bank examiner about the good and bad application security practices he’s observed at financial institutions. Get the location and time at our chapter website. I hope to see you there.

Defcon 2007

2007-08-23T07:05:00.000-07:00

The Security PS consulting team recently attended Defcon 15. With five tracks running over three days, the conference jam-packed enough hacking techniques, exploits, and security news into our heads that I’m afraid I may have blown a fuse from information overload. The presentations covered everything from Wifi attacks to application security to hardware hacking, and speakers like Bruce Schneier, Johnny Long, and Dan Kaminsky didn’t disappoint packed audiences.

When one of your job requirements is keeping up with an entire world full of blackhat hackers, it’s helpful that once a year they all get together and tell you what they’re up to. We will be posting highlights from various talks over the next few weeks. Stay tuned.

Banks fail to meet FFIEC multi-factor authentication requirements

2007-08-06T08:30:00.000-07:00

By the end of 2006, U.S. financial institutions were told to comply with the FFIEC’s updated guidance on authentication for Internet banking. This guidance instructed financial institutions to use multi-factor authentication, along with other security controls, for any online applications that allowed "high risk" transactions. Consequently, banks, credit unions, and other organizations hustled to integrate new authentication solutions that could satisfy bank examiners and reduce online fraud.

Did they succeed? One recently published study says no. In a paper titled Trends in U.S. Multi-factor Non-Compliance, Sestus Data Company and BearingPoint Financial Services report that only 4% of the 100 banks sampled consistently required multi-factor authentication. If this sample is representative of all U.S. financial institutions, and I feel fairly comfortable that it is, we appear to have a serious problem.

The main reason for the failing grade comes from conflicting interpretations of the term "multi-factor authentication". As the report points out, 90% of financial institutions have implemented additional authentication requirements in the form of challenge questions. However the FFIEC’s original guidance and subsequent FAQ explicitly require multi-factor authentication solutions to combine at least two of the three authentication factor types: what you know, what you have, and what you are. Combining challenge questions with passwords only builds upon the single factor category of 'what you know'.

So, the big question then becomes why are bank examiners are allowing financial institutions to get away with solutions that don’t meet the defined criteria. Just to be clear, I haven’t heard any official answer to this so I can only share my theories.

The new FFIEC authentication guidance was a pretty big shock to the many financial institutions who had given limited attention to their online application security. I can tell you from experience that some of these organizations were failing to establish and enforce even basic password requirements for customers.

Many financial institutions undoubtedly raised objections when they were told to skip the step of improving passwords altogether and jump directly to implementing multi-factor authentication. Especially when this jump meant investing around $15 - $30 per user before the 2007 deadline. Some of these organizations were tempted to find lower cost solutions that would address some of the FFIEC’s concerns about authentication attacks.

At this point bank examiners could have sat down with the financial institutions and told them that these changes were inadequate. Astonishingly, I haven’t seen or heard anything to indicate that these conversations ever took place.

Maybe bank examiners are at odds with the FFIEC personnel who pushed the requirements for true multi-factor authentication. Maybe they are willing to allow partial compliance with the guidance to see if these stopgap solutions still reduce fraud. They could still come back later and tell banks that they need to improve the ineffective authentication solutions. Maybe the examiners decided too late that the requirements were too drastic and are quietly allowing compromises by financial institutions so the FFIEC can save face.

Regardless of the motive, I don’t like the result. The financial institutions who took the guidance literally are now at a competitive disadvantage to those who didn’t. They probably have better authentication security but they are also likely to have spent more money on a multi-factor authentication solution. People don’t always like what’s good for them, especially when it includes a significant change, and a stronger authentication system may drive some customers to a competitor who has laxer security standards.

This is the wrong message for the government to send to financial institutions and consumers. Financial institutions may drag their feed in complying with any future security requirements until they find out what examiners will really require of them. Both customers and financial institutions will remain exposed to threats longer than necessary during this waiting process.

If you would like to share your perspectives on compliance with the FFIEC’s multi-factor authentication guidance, leave a comment. I’d love to hear your thoughts.

Tips for Avoiding Bad Authentication Challenge Questions

2007-07-17T12:38:00.000-07:00

I’m excited to share the news about a brand new white paper from Security PS. We’ve had clients requesting this information for months, and I'm glad we can finally share it in a written form. This is also the white paper Kris and I discussed in the App Security Advisor Multi-Factor and Risk Based Authentication podcast.

The paper is called Tips for Avoiding Bad Authentication Challenge Questions. To be clear, a challenge question is a question used for authentication that asks you for personal information. Examples are “what is your mother’s maiden name” and “what is your pet’s name”. Financial institutions, including many of our clients, have implemented challenge questions in an effort to improve online authentication for higher risk applications.

My goal with this paper was to review how well these questions actually succeed in effectively authenticating users. I subjected challenge questions to a framework for evaluating authenticators that I developed several years ago. I also gathered a variety of examples from clients and public sources so I could illustrate the strengths and weaknesses of different questions. I think you may be surprised by our conclusions.

If your organization has implemented challenge question authentication or are simply interested in how much security they provide, I encourage you to give it a read. I’d love to get your feedback about the paper. Please enter your comments on this blog entry or send me an email directly. You’ll find my contact information at the end of the paper.

Paper link: http://securityps.infosecmedia.com/whitepapers/TipsforAvoidingBadQuestions.pdf

New App Security Resource

2007-06-25T06:50:00.000-07:00

The App Security Advisor blog and podcast has been released. While you can read and listen to the first post on the web site to hear what the resource is all about, I'll give a quick recap here.

In short, The App Security Advisor podcast discusses hot topics in the world of application security and provides insight to where the industry is at, what pitfalls companies are hitting, and what proven practices can be applied for the most effective results. Many of the discussions will be strategic and well-suited for director and executive level audiences who require insight for moving forward with application security initiatives. However, there will also be a number of segments that are technical in nature to help the technical managers and development team leaders get a handle on the technical side of the challenges and solutions.

Current topics include multi-factor authentication pitfalls, security in the SDLC, and gauging the effectiveness of app security initiatives. Other topics on the way include technical authentication gotchas, top 5 questions to ask your application vendor, and web services/SOA security.

The segments will have mini-seminars, interviews with industry experts, and question/answer segments. Leave comments on the blog or send e-mail to have your questions included in the Q/A segments, or to provide direction for future topics.

When to Assign Users Responsibility for Security

2007-04-30T08:26:00.000-07:00

First, I wanted to mention that the Security PS blog is now one year old. We thank those of you who have scrutinized and shared our content in an effort to increase awareness of information security issues. We also encourage you to continue submitting your questions or blog entry ideas with us via the comments section or email. With your feedback we can continue to provide expert coverage of the security issues that are important to you.

Second, I want to share my concerns about a security practice that has been bothering me for some time. Almost every application or network consists of users with vastly different levels of security awareness and skill. For every company that has a user like me (my bio claims I'm pretty security savvy) they have hundreds of users that are less aware of the security threats they face. So why is it in some cases those same users are required to make important security decisions?

In this case I'm referring to the growing trend of asking users to set their own custom security questions and answers. These are the questions and answers commonly used to provide a fallback option for authenticating when a password is forgotten; or used to further validate an identity when a username and password are deemed insufficiently secure. We are seeing this built into more online financial applications in an attempt to meet the FFIEC's new authentication requirements.

My main concern is that the user can customize the questions, not necessarily that the questions and answers are used for authentication. In these situations the answers to the questions act as a substitute for, or an equivalent to, a password. Logically, they must be held to the same standards of security that passwords are. They must not be easily guessed or predicted. They must collectively ensure that only the authorized individual can provide the correct answers.

Yet this is not the main issue of concern for most users when selecting these questions and answers. They are focused on choosing a question and answer that they can easily remember. This is also important, but it cannot take priority over the confidentiality of the information.

When a user sets up a question like "what is my favorite color" -- and they do -- they have not only limited themselves to a fairly small selection of answers, but they have also chosen to prompt for a piece of information that is not considered a secret. They are likely to share the information if asked by a family member, friend, or possibly even a casual acquaintance.

How can this be considered the security equivalent of a password?

Sadly, this has been a known issue for some time. Organizations first started experiencing similar problems when they allowed users to create customized password hints. Nothing stopped users from making their hints blatantly obvious (such as "a day of the week") or even putting their password directly in this field.

Professionals cannot in good conscience allow these decisions to be delegated to the users. Claims about it being the user's responsibility to make good choices, at least in this area, simply don't make sense in today's hostile Internet environment. If you see it fit to enforce minimum password standards you must also commit to enforcing minimum question and answer standards.

The simple solution is allowing the user to select from a library of predefined questions instead of creating their own. You should select these questions with the uniqueness and confidentiality of the answers in mind. Here are some of the better examples:

- Who is your favorite character in a book?
- Who was your favorite teacher?
- What was the name of your first crush?

Want more feedback on securely implementing question and answer based authentication? Send me an email and I’ll be happy to share my thoughts.

Searching Google for SQL Injection Targets

2007-03-01T07:58:00.000-08:00

SPI Dynamics recently had an on-demand webcast where they scanned around 1000 sites using the Google API for SQL injection. The scanning application returned approximately 700 sites that actually responded to their queries. They only did simple SQL injection tests using a very basic SQL string. Also, they only looked at sites that actually returned verbose SQL responses. Even with this very small and restricted subset, they found that 11% of sites returned verbose SQL errors. The presenter goes on to say that he thought that this estimate was representative of the population but is likely a lot higher than that.

Based on the presentation, it sounds like there are lots of vulnerable web apps out there. It is kind of interesting to me that even in this day and age, SQL injection is still so common. Thankfully, the presentation also provides the best approach to prevent SQL injection vulnerabilities; validation based on whitelists, and sound queries through parameterization.

Check it out when you have 15 minutes or so.
https://download.spidynamics.com/registration/SQL_webcast.asp

Cross-Site Scripting in Adobe Plug-In

2007-01-05T12:41:00.000-08:00

You may have seen the recent flurry of news stories surrounding a cross-site scripting (XSS) vulnerability in Adobe's PDF browser plug-in. In case you missed it, here are a few articles that provide an overview of the problem:

Washington Post
USA Today
Information Week

Essentially, the vulnerability provides yet another way for an attacker to execute JavaScript in another user's browser when the user follows a specially crafted URL to a PDF file. By adding JavaScript commands to parameters in the URL, attackers can steal cookies and sensitive data, change the appearance or behavior of the site, and redirect users off-site in phishing attacks. To make matters worse, the attack string (the part that does the damage) in the URL is never even sent to the web server, so the attack can't be stopped by having the server look for dangerous JavaScript in requests for PDF files.

So, what can an organization do to protect its users from being attacked through PDF files stored on its web site? There is no foolproof solution, but the best approach is trying to prevent the vulnerable Adobe browser plug-in from running, which can be accomplished in some browsers by changing HTTP headers in the web server response. There are two relevant headers that could be changed:

  Content-Type: application/octet
  Content-Disposition: Attachment

Both of these headers instruct the browser to download the file instead of opening it in the vulnerable Adobe plugin. We have followed this approach on our own servers and it prevents the attack in most cases. This morning, Google and Yahoo followed suit with a similar fix.

Here are instructions for adding these headers to the server response for PDF documents in Apache and IIS.

Apache:

Add these lines to the httpd.conf file inside the <Directory> tags.

  AddType application/octet .pdf
  <Files *.pdf>
    Header add Content-Disposition "Attachment"
  </Files>

IIS (tested in 6.0, these instructions may vary some for older versions of IIS):

Change MIME type to "application/octet":

Start > Run > Enter compmgmt.msc. The Computer Management console appears.
Right click on the Services and Applications > Internet Information Services (IIS Manager)
Select Properties > MIME Types
Scroll down to ".pdf". The MIME type should be "application/pdf". Change this to "application/octet".
Click OK twice.

Add Content-Disposition header (this must be done by directory or for each PDF file individually):

In the IIS Management tool (not in Windows Explorer), select a directory with PDF content or an individual PDF file.
Right-click on the directory or file.
Select Properties.
Click the HTTP Headers tab.
In the Custom HTTP Headers section, click Add.
A dialog appears. In the "Custom-header name" field enter "Content-disposition". In the "Custom-header value field, enter "Attachment".
Click OK twice.
Restart IIS (command line: iisreset).
Check that PDF content from the browser now prompts the user to "download" rather than simply opening the content.

This is not a 100% solution, but changing the HTTP response headers will go a long way toward reducing the risk to users of your site. Although this works in current versions of the more popular browsers, it is possible that some browsers could ignore these headers and open the PDF with the Adobe plugin anyway.

It may also be possible to address the vulnerability programmatically. Some examples have been published for Java and .Net. These examples have not been tested by Security PS, but they have been proposed as a way to help prevent attackers from exploiting the Adobe plug-in vulnerability.

If you implement these or other changes, please let us know about your experience.

MySpace and the Case Against Input Scrubbing

2006-10-02T06:32:00.000-07:00

If you haven’t heard of MySpace.com, it’s safe to say you’re not a teenager. MySpace and other social networking sites have skyrocketed in popularity recently. The site allows users to create a unique homepage and customize it by adding HTML and style sheets. Each user essentially gets to build his or her own mini-website within the MySpace environment.

This creates some interesting challenges for managing site security. While not responsible for the user content, MySpace is still obligated to protect users from each other. To accomplish this MySpace allows users to enter “safe” HTML and style sheet tags, but has to prevent “unsafe” tags to avoid attacks like cross-site scripting (XSS). Their solution has been to compile a list of every bad tag or pattern they can think of and try to “scrub” these patterns out of incoming data. So, if you tried to use a JavaScript command like this on your homepage:

<script>alert(‘xss’);</script>

MySpace would recognize the script tags in that pattern as being unsafe and remove them.

The problem with this approach is that there are a huge number of ways to get a script to run on a user’s browser and MySpace can’t keep up with them all. In fact, there have been a number of vulnerabilities reported about this very problem. These security issues will continue to crop up as long as MySpace attempts to prevent them by scrubbing bad data out of user input. In fact, Security PS has knowledge of at least two previously unknown cross-site scripting vulnerabilities on the MySpace site. We are working with MySpace to address these issues.

As our clients know, the only way to really remove assumptions about incoming data is to positively match it against a very specific pattern. MySpace should define a patterns for each HTML tag they consider safe. They could then match incoming data against these patterns and deny any input that doesn’t match the pattern for a known tag. By doing this, they will no longer have to keep up with every new attack in existence. Each new attack will be automatically denied by the data patterns. Until they do this, they will continue to fight a losing battle against attackers.

Examining the protection provided by SSL

2006-08-17T08:20:00.000-07:00

If you’ve attended one of our web application security classes or seminars you’ve probably heard us say “SSL does not provide application security.” It’s true. While SSL can provide great protection for data traveling across a network, it doesn’t do anything to stop most web application attacks.

Which isn’t to say we discourage SSL; just the opposite is true. You should use SSL any time you need to protect the transmission of user credentials, authentication session IDs, or other confidential content. SSL can go a long ways towards making sure your users can still safely use your application even when connecting over untrusted networks.

One question we are frequently asked is “does SSL protect the contents of URLs as well as the contents of web pages?” The answer is yes. If your application stores sensitive information as parameters in the URL these values are not exposed to anyone other than the user. The same goes for all other information in the HTTPS header. A bad guy sniffing network traffic will only see packets containing basic TCP/IP information and an encrypted data payload traveling between the client and web server.

Another question we hear is “when does SSL start protecting transmitted data?” These folks are typically worried that sensitive URL parameters might be exposed if they are included in the very first HTTPS request to the web server. Luckily, these requests are also protected.

Here’s how SSL works: A client performs a basic TCP/IP handshake with the web server, then completes the SSL certificate and key exchange, and finally requests the URL over the encrypted channel. It’s nice to know your data can be encrypted from beginning to end using SSL.

Have other questions about SSL? Let us know and we will try to answer it in an upcoming blog post.

Don’t let scammers redirect customer anger at you

2006-06-22T10:03:00.000-07:00

A recent edition of the RISKS digest reports on the receipt of an interesting phishing email. Like most phishing attacks, the email informs the reader that their bank account status (at Barclays Bank in this case) is in jeopardy. To keep their account in good standing the reader is required to log into the online banking service, and to facilitate this process they just need to click the provided link.

Normally this link takes them directly to the attacker’s site, configured to impersonate the legitimate bank site. To add legitimacy to the email, an attacker often tries to obscure the fact that the reader is being directed to their site instead of the real bank. They may use an IP address, a slight variation of the legitimate site’s DNS domain, a HTML hyperlink, or another method of obfuscation.

But this particular link actually did take readers to the legitimate Barclays Bank site, at least initially. Here is a safe sample link that mimics what was contained in the phishing email:

http://www.barclays.co.uk/cgi-bin/gotosite.cgi?location=%68%74%74%70%3A%2F%2F%77%77%77%2E%73%65%63%75%72%69%74%79%70%73%2E%63%6F%6D

As you can see, the link does point to Barclays Bank. But it requests a CGI script that is designed to redirect your browser to the URL contained in the ‘location’ parameter. And the URL in the location parameter is encoded to prevent you from seeing that it really looks like this:

http://www.barclays.co.uk/cgi-bin/gotosite.cgi?location=http://www.securityps.com

So, visiting this link does take you to Barclays, but also immediately redirects you (via a HTTP 302 response) to the Security PS Web site. An attacker might make use of this feature to convince an only slightly savvy reader that the link is safe to follow.

So a good question is why does Barclays support this feature? Barclays may have intended the cgi for use in site navigation, in which case the location parameter should only contain references to another page on their site. However, if they fail to actually constrain this functionality they end up supporting offsite links as well.

Barclays isn’t alone in having their application’s functionality abused by criminals. Both Visa and eBay fell victim to the same issue last year. They both eventually modified their application when the abuse received public attention.

To their credit, Barclays does try to educate its customers about phishing and other email scams: http://www.personal.barclays.co.uk/BRC1/jsp/brccontrol?task=articleFWvi2&value=9190&target=_self&site=pfs They specifically instruct customers not to click on any links they receive in emails purporting to be from Barclays. But try explaining this to an angry customer who thinks your Web site facilitated fraud against them.

While this certainly isn’t a critical risk – stealing credentials by exploiting a cross-site scripting attack on your site would be much worse – it is important to recognize that the feature has potential for abuse. Find out if your Web applications have a similar feature. If they do, we recommend that you eliminate or constrain the redirect functionality.

Integrating security into the SDLC

2006-05-11T09:04:00.000-07:00

Recently I stumbled upon an article about integrating security into the development lifecycle without adversely affecting the normal development process. The article was written by Gary McGraw, and I found it to be a good read. The article discusses some of the problems with the security process as it pertains to the SDLC, and how to address them. I’ll discuss a few of the notes that I picked up from it.

In his article, Gary McGraw observes three phases of organizational maturity from a security perspective:

Organizations that don’t fully understand the security problem
Organizations that are in a constant “reactive” mode
Organizations that are integrating security best practices into their SDLC

McGraw goes on to describe best practice items that can help improve the security of software. The following outlines the process that a mature organization might follow to ensure more secure software.

Perform a code review using static code review and black box testing tools.
Perform a security architecture review.
Get penetration testing completed.
Attack the application like an actual intruder would (“Risk based security testing”).
Understand the application “Use case” scenarios.
Understand the application “Abuse cases” - how an attacker might use it in the future.
Ensure that traditional security measures are in place for the environment (Firewalls, IDS, monitoring, patching).

Even if all of the above aren’t followed, McGraw points out that the most important things to consider would be performing code and architecture reviews. “I think those are the first two that everybody should be doing today. So if you're only going to do two, do those two.”

In closing McGraw mentions that it is important to get the support of both management and the developers to ensure a successful secure development lifecycle. Combining the support of those involved will help to drive more secure applications.

To read the full article in its entirety, see http://searchappsecurity.techtarget.com/qna/0,289202,sid92_gci1187360,00.html.

Microsoft releases library to help mitigate cross-site scripting

2006-04-17T13:08:00.000-07:00

Many web applications today exhibit security vulnerabilities due to the lack of proper input validation and output encoding. Though numerous development platforms exist, none have a foolproof way to provide complete protection from attacks such as parameter manipulation or cross-site scripting (XSS). Even modern and robust frameworks such as Microsoft .NET are no exception.

However, Web applications written with .NET, in a language such as C#, can utilize many new and interesting approaches to solving input and output vulnerabilities. The attribute validateRequest, for example, can force a .NET application to check for the existence of script-based attacks.

The validateRequest functionality checks for the presence of patterns containing an angle bracket and an alpha character. Under many circumstances, this will prevent a XSS attack. However, when values are written dynamically to HTML, angle brackets are not needed, and an exploit remains possible. Then there are times when developers may choose to disable validateRequest, in which case there is no default protection against XSS attacks.

To aid in mitigating these threats, Microsoft recently released a programming class to prevent XSS vulnerabilities. The Microsoft Anti-Cross Site Scripting Library performs transformations of certain special characters into their HTML entity equivalents, or URL encoded equivalents for items that need to be passed in the URL. For example, <, when run through the HTMLEncode() method will now be safely rendered by the browser as &60;, which is the hexadecimal form of the less-than sign.

Some scenarios will still permit XSS attacks. Developers should use the URLEncode() method to write information that will be sent via URL, such as links. It is therefore critical to apply this as another layer of data validation and encoding security and not use it as your only defense.

Programmers using .NET that wish to make use of this in their applications as an approach to defense-in-depth can obtain it for free from the Microsoft website.

Web application attacks on the rise

2006-04-13T18:08:00.000-07:00

According to statistics gathered by the Web Application Security Consortium and reported by Information Week, attacks against Web applications are on the rise. In fact, if the trend continues to the end of the year, 2006 will be the worst year on record for Web application security breaches. According to the article, this is happening for two reasons:

1. The prevalence and availability of tools that make it easier to find and exploit vulnerabilities in Web applications.
2. Web applications aren't often designed with security in mind.

There are even more reasons for this trend than those covered in the article, such as the emergence of worms and other automated attacks that target vulnerabilities in Web applications. Furthermore, knowledge of Web application attacks is becoming commonplace, reducing the average attacker's reliance on tools. Many attackers now need only a browser to wreak havoc in a poorly designed Web application.

The latter point, however, is the crux of the problem. Web applications that weren't designed with security in mind are far more likely to have problems later on. Even if the problems are discovered before they hit the news, it is costly and difficult to retrofit an application with security controls. On the other hand, when security is incorporated into the software development lifecycle from the beginning, the application is prone to fewer vulnerabilities and is much less likely to end up on the news because of an intrusion.

Google spider deletes application content

2006-04-12T16:28:00.000-07:00

A recent item in the news (http://www.thedailywtf.com/forums/65974/ShowPost.aspx) reminds us of two important Web application security tips:
1. Don’t fail into an insecure mode by default
2. Be careful running automated spidering software on your applications.

This story took place during development of a Web content management application. One morning the dev team came in to find that all content had been erased. An investigation of the incident linked blame for the deletions on an IP address associated with one of Google’s Web spidering servers. Logs revealed that the spidering software was indexing the site when it came upon a link for content editing. Like a good spider, it followed the link.

Application access controls should have required authentication at this point, effectively stopping the spider from anonymously changing anything on the site. This particiular application assigned a cookie parameter named “isLoggedOn” with a default value of “false”. Once a user authenticated, the app changed this value to “true”. Unfortunately, the application only denied access if the value was set to “false”. Any other value, or the absence of a value altogether, would permit the requested operation.

As you may have guessed, the Google spider was able to successfully enter page editing mode because it didn’t accept the original cookie from the application. Thus is passed the badly written authorization test. Once in edit mode it dutifully continued following all links, including the “Delete Page” option. Any curious hacker could have done the same thing.

Obviously the problem could have been prevented by better programming. Applications should operate by authorizing only requests that are accompanied with legitimate authentication credentials (like a unique session ID) and not by the absence of a value.

The story also acts as a good reminder that spidering a web application can have unintended consequences. If you are using automated vulnerability scanning software that spiders content during testing, it can cause the same negative impacts. This is why Security PS assessments include time for us to manually walk through applications and identify issues like a link that logs out of the application or deletes a user account. These links can then usually be placed in an exception list so they are avoided by any subsequent spidering.

Which is nice, because it allows you to spend time doing something more exciting than running to grab the latest backup tape for your server.

Welcome to the Security PS Blog

2006-03-06T09:34:00.000-08:00

In security assessment after security assessment we find those organizations that focus on educating employees about of security threats and countermeasures do far better than those who don’t. To support this effort, we introduce the Security PS blog.

Our goal for this blog is to supplement our other forms of client communication (like our quarterly newsletter and training sessions) with more frequent tips. These entries will range from links for newly released security reports and standards, to brief commentaries on computer attacks covered by the media.

As always, we’re interested in your feedback on blog entries or requests for more information. Feel free to contact us at info@securityps.com or visit our website at www.securityps.com.