A Possibly Fresh perspective about Secure Code for Software Development Companies

I am sure most of you wont believe the reasons for my hiatus for almost 4 months. Let me try and explain. I was involved in a theater production very dear to my heart, so my evenings would be lost in that. I am pursuing a heavy writing assignment, which has been uber-demanding on the small space of time I have left and I actually took my vacation in September, when I had been to beautiful South Africa. Great place! You guys must all visit.

Anyway, enough with the chatter. This piece was prompted by a talk I heard at the Business Technology Summita few days ago. Of course, I blabbed about web app sec and scared the pants off a few nervous developers and architects, but it was mostly fun. The conference mostly focused on SOA ang governance, but there were a few pure tech talks. There was one talk, which I was quite impressed with, by a fellow Java man, Eben Hewitt. He spoke on a topic entitled "10 Things Software Architects must know", which is based on a book similarly entitled, except that the '10' has been replaced with '97'. The talk was mostly about concepts which software architects should keep in mind in order to be successful. While the talk didnt really have a specific security-related context, I applied some of those theories to the way software development companies can deal with security for the apps they develop. These are just my two cents. I am sure some of you can add more to it.

I have heard of several instances where software development companies have been severely criticized for writing non-secure code. Undoubtedly so. Several software development companies dont really take secure coding to be an important practice. Time is not spent developing security in the application from the beginning, which subsequently results in a non-secure web app. The most common excuse that most of these entities give in terms of security or any other functionality not implemented is "This type of security functionality was not laid out in our Requirements Specification" or "There was nothing in RFC specifying these security requirements" and blame is thrown right back at the customers or the business users of the application for their lack of foresight. It is as if we believe that customers who will be using the application or who are functional stakeholders of a web application are actually extremely clear about their requirements. The truth is very simple. They are as clueless as you are. In most cases, they will never really know what they want even functionally, unless they are given several ideas, security is quite a mile away in these circumstances. I believe that it is upto the company or the team developing the application to incorporate a risk assessment process to ensure that they capture all the critical information assets that will be stored, processed and transmitted by the application, threats and the impact of an attack on the application and subsequently on business, and then draw out security controls for the same. I have highlighted a detailed methodology for risk assessment for web apps, in my book "Secure Java for Web Application Development".It is wrong to assume that customers or business stakeholders will be able to provide the razor sharp clarity necessary to build security into an application. Software Development companies need to rise to the occasion and use their expertise to suggest solutions and functionality for security at the beginning of the application development lifecycle.

Which brings me to my second point. People reading my first point are going, "Yeah, but isnt that going to be more expensive than a regular application development effort, without going Mother Teresa on my customer?" Yes it will be a longer, probably marginally more expensive process, but Quality is a Feature. We all try and sort out all problems all the time. Let us not try to do that and examine reality. Software development companies focussed on a greater level of quality of their products must make it explicit. You have various product and service offerings today, but it is important to realize that all services and products will not be of the same quality. A restaurant on the roadside, will not be as focused on quality than a snazzy five star restaurant. Its high time that we understood that about code as well. And its also high time that software development companies that are taking the first point seriously, start making it explicit and derive as much benefit as possible. There may be customers out there (despite the recession) that may be willing to pay better for a better service that is accentuated and re-iterated by processes like Risk assessment, effective understanding security functionality at the start of the lifecycle, vulnerability assessments, security code reviews and practices delving into security. Superior quality, in my opinion is a feature by itself, which needs to be advertised, and made explicit and should not be spoken about or practiced like its a part of the proverbial 'package'.

Let me know what you think of this....

Rediff XSS, the redux

It seems like my praise for Rediff was too quick. I had not tested out the Rediff search site exhaustively. This was brought to my attention by an OWASP Delhi member. Apparently, our friends at Rediff have not "fixed" the XSS Vulnerability in the search area. My attempts at performing a rudimentary XSS were thwarted, but I hadnt explored the possibility of encoding my payload using Javascript escape(), so this time, I tried and came up with this:













Apparently, the folks at Rediff have performed some very poor input validation and have probably only filtered the "<" and ">".

Rediff Redressal.....

My good deed was done for the week. Everytime one does something good for something or someone, one tends to feel good about it, sometimes even gloat about it.

I was surfing the Rediff Site yesterday, yes, the same one which I had eviscerated previously and entered the vile xss script and expected another tirade of scripts to rain down, but to my surprise discovered that it had been fixed. No more output encoding issues and the malicious payload seemed to have been encoded to prevent malicious XSS payload

Here is the screenshot.














But unfortunately, Rediff has not fixed a small pothole, whereas a large patch of road still remains undone. Several other Rediff sites (Rediff Products) are still vulnerable to XSS.

Screenshot:

OWASP Chennai Meet - 17 May 2009

The OWASP Chennai Chapter meet was held on the 17th of May 2009 at Chennai. It was very nice to see some dynamism from the OWASP Community in India. I am happy to see great steps being taken by the Chennai OWASP Team (Chandrasekar and the rest) in taking initiative.

The talks scheduled for the day were on Globalization and its role in Information Security and Mobile Crimes

I was invited to speak and I spoke on Application Security Risk, in a talk entitled "Application Security Risk - The Full Circle"

Here's the presentation:

OWASP Chennai Talk - Application Security Risk - The Full Circle

View more presentations from abhaybhargav.

This presentation highlights the importance of Application Security Risk and how to perform effective and comprehensive Risk Assessments for Web Applications to provide for a robust protection strategy. It highlights how an effective Application Security Risk Assessment can result in the development of a secure SDLC, feed the Security Testing area with threat modeling and the development of "Abuse Cases" and become the foundation for a strong and secure web application.

Who's got the last laugh now. The Blogger XSS Vulnerability

I guess I was asking for punishment. I go looking for Web App Vulnerabilities all over the world, and sure as hell, this is what I will get.

I discovered that once I posted my Rediff Search Engine XSS Vulnerability on Blogger, I noticed something I had seen all too often, the Javascript alert with the rudimentary XSS, and this time, it was on my blog. I was not to happy about it to say the least. I thought "Some Smart Alec must have written up a comment causing the XSS alert, but I was quite sure that couldnt happen because Blogger had some sort of a filter on the comments. I then realized that the XSS alerts were popping up because of the XSS vectors in my Rediff post.

Surprisingly Blogger does not do any kind of validation or output encoding to prevent against these attacks in the posts section. So the blog-author can potentially be serving up XSS on his/her blog and potentially be exposing all the visitor's accounts with that, and since Blogger is a Google service, my session credentials are good for any Google Website. Mail, docs, everything.

But its ok now folks, the bitter pill of my own medicine has been swallowed................ or has it?

Rediff Search Engine XSS Vulnerability

This was something which was quite shocking as the series of events unfolded. I was researching up on output encoding methods to prevent against Cross Site Scripting and I experienced the full blown effect of the evils of bad/no output encoding and of course, no Input validation.

This was something I discovered on Rediff.com's search engine. When I typed in "search:followed by the Javascript alert, I received the infamous Javascript alert with simple 'XSS' written all over it. I was a little perturbed, because my NoScript said that it blocked a cross site scripting attack against taking place, but why was the alert still popping up? Then I was sure that the site was vulnerable to cross site scripting and decided to write about it. When I clicked the "Ok" on the Javascript alert box, another one popped up. This was definitely odd, I hadnt configured the alert for more than once. Then I clicked OK once more to find that there were more Javascript alerts to arrive with things like "XSS", session cookie details, "try_xss" and other alerts which I hadn't written. I then realized that rediff's search engine is scouring the web for pages with the XSS variants was executing that script on the rediff site, which was, beyond imagination and quite horrible. As I was clicking "OK" on the Javascript alert boxes new search results kept showing up and new alerts kept popping. The alerts only stopped with the end of the page.

Not only is Rediff vulnerable to XSS, Rediff has failed to encode their outputs from the search engine and is serving the xss, fresh from other websites, which have ironically, encoded their outputs.


I tried this out on a Google page, but it didn't work .

Anyone want to play around with the Search string try and enter your regular XSS reflected XSS tags check it out.

I have informed Rediff about the vulnerability, hopefully, they should rectify it soon.


Here are the series of screenshots of the xss alerts and the search results expanding each time.

The Berkeley Data Theft

I just received word that the University of Berkeley has had a major security incident.

The Campus Health Services Center databases have been hacked (supposedly by foreign hackers) and over 160,000 records of PII (Personally Identifiable Information) have been exposed and may have been stolen.

According to the university, the databases contained individuals' Social Security numbers, health insurance information and non-treatment medical information, such as immunization records and names of some of the physicians they may have seen for diagnoses or treatment.

It is believed that the breach began sometime in the month of October 2008 and continued till April 9th 2009, when the campus administrators discovered the breach. The University has said "The attackers accessed a public Web site and subsequently bypassed additional secured databases stored on the same server."

This seems like another Web Application attack, where the attackers have been able to gain access to Databases using the Web applications and cause the breach. It might be a case of SQL injection coupled with various other types of attacks.

This is a "wake up call" for universities all around the world. Universities are perhaps the largest repositories of data (student data) and they have access to sensitive information about the students. Such breaches can cause massive instances of identity theft.

I find this even more alarming thinking about the Indian state of affairs. India's universities have recently taken to computerization and the number of students in Indian universities is a mind-boggling number of something like 8-10 million. Such security incidents put all that data at risk.

Incredulous Interactions with Web Application Developers: 2 of Many

Here's wishing that all of you have a good weekend. I left early from the office today to attend to some household duties. While I was sitting and watching TV, I came up with a concept, which resulted in this title. I interact with several application developers over the past few years and now as I steeped in AppSec, I have been interacting with a lot of Web Application Developers during my application assessments. Normally, they are a nice bunch, who are quite convinced about the authenticity of my claims of having their applications torn apart on the internet. But, everytime I discuss security, there are always this few developers who end up astounding me or completely disarming my constant efforts to bring about change in the way they think (or don't think) about Web Application Security . I thought, "Why not chronicle my interactions with these people, for the benefit of the community, and for a few laughs (or atleast a smile) in the normally tense lives of security folk?", and so, I present to you, the second in the series of "Incredulous interactions with Web Application Developers". You might be wondering what happened to the first of the series. It is the first entry in this blog, but has not been grouped under this title. Anyway here it goes....

It was at the end of the day, and I had almost finished assessing this application. The application was being developed by a small group of developers working for a small company. Their product claimed to be the only one of its kind and one of their potential clients wanted the application to reviewed for security.

I had reviewed the Application for over 2 days. I had spent some time interacting with the project manager and the developers, and had performed a combination of black and white-box tests on the application. The application had some serious issues, there was almost no validation and whatever little validation it had, it was on the client-side, utilizing trusty old Javascript. I knew it was a problem. The developers were quite sold when I showed them a Cross Site scripting PoC as well as a Embedded Flash injection PoC. The only problem was getting through to the Project Manager. He was not convinced, and a conversation on the following lines ensued.

I used Burp proxy to perform my scripting attacks and he said this. "This application is going to be used only by the Company employees. why will they want to steal this data from the company?", for which I gave him standard insider threat lecture, statistics, et all. I tried explaining to him the fact, that this application stored extremely sensitive data (which it did) and an insider would also have a clear motivation to break into the application to steal information, not to mention disgruntled employees, or other employees with malicious intent. I also explained to him the CSRF angle, where this site might be attacked by another site violating the same origin policy.

He was yet unconvinced and he said, trying desperately to prove a point, "I have worked for over 12 years in Software development and have developed dozens of applications, never before has a client asked me for all the security features you are asking me for, it seems that you just want to prove a point." I burst out laughing at this and told him that if he believed that his potential clients weren't concerned about security, then they wouldn't have engaged my services to perform the assessment. I also had to tell him, that the way he or anyone else has been developing web apps in the cavalier manner that they have been all these years, does not make it right. Quantity is not quality, I told him and I also informed him of the fact, that awareness has been rising in the community about the effects of web application attacks, which is the reason why, if he wants his product to remain competitive and viable in any market, he would have to do "complicated things" like input validation based on a whitelist of "known good" characters to prevent against a smorgasbord of attacks. I told him finally that it would be for the benefit of the application and the data it holds as all these measures would prevent against any untoward incidents and not result in loss of reputation for his company. The man finally backed down after that and we discussed some implementation strategies for input validation across his web app.

This got me thinking, that developers have churned out several thousands of web applications which are working all over the internet and organizational intranets over the years. This was a single project manager from a single small company, who had himself been involved in the development of over 20 applications in his career. It would be quite scary to think of other developers over the years who would have developed similar applications with similar if not worse vulnerabilities.........

Overreliance on Javascript: Pen-tester's pet

I am sure all of you have been acquainted with the input validation situation where the developer validates all his input on the client-side using some poorly written Javascript to boot. Well, I recently experienced a new high in Javascript overreliance, and this was precious!!

I came across an application which relied heavily on Role Based Access Control. The Application is an Enterprise Application which has several types of users and several different "screens" that each user can access, thereby restricting the user's access based on the user's role. Well, this is how a traditional access control system works.

So, what would one do to ordinarily circumvent these controls? The first thing I tried was the URL route, where I scanned the app for URLs and entered these URLs to elevate my privileges. I was easily able to do this and the pages that clearly weren't meant for my user role kept appearing. When I tried to input some data and submit the form, the server threw me a big fat Javascript alert, "Access Denied".

Then I revoked the temporary permissions on my NoScript and the entire application fell apart. The Application so heavily relied on Javascript that the access to the links was controlled using Javascript only.

The code went something like this:

function Menu()
 {
 var UserRole=document.getElementById('userRole').value;

 switch(UserRole)
 {
 case 'elevatedPrivUser':      
  document.getElementById('thisScreen').style.display='none'; 
  break;
 case  'lowerPrivUser':       
  document.getElementById('someOtherScreen').style.display='none';
  break;
 case 'evenLowerPrivUser':
  document.getElementById('yetAnotherScreen').style.display='none';
  break;

As you can see here the Developer had left this brilliant bit of Javascript on each and every page. This was the basis of the Role Based Access Control System of the Application. Then I thought, surely, even if I accessed any one of these pages and tried to submit a request, the server would stonewall me and throw me out. I tried it out. Guess what?....More Javascript. Luckily, the Javascript wasnt available on plain view in that page, but clearly Javascript was the only validation which had been provided to validate user role and by disabling Javascript, I was able to pass my request over to the server which was accepted instantaneously.

So, the next time I go try to test an app for elevation of privileges, I will not bother with the session hijacking or the sniffing. I will just ask my NoScript to do the job and I will check whether the developer believes that "Client-side Scripting is the best!!!!"

Payment Application Pacman

Lately, I have been flooded with Application Security Assessment work. Applications of all forms, shapes and sizes have been given to me to test, which I have gleefully accepted. The work is supremely interesting. I always knew that there were tons of applications being developed all over the place, but I always figured that they would be of a certain nature, like a plain vanilla E-Commerce Application or a Banking Application, etc. Because of the spate of application security testing I have been doing recently, I have found that there is an application for everything. Right from Flea-Market Management to Cold Storage Management Applications. The granularity of business verticals which applications are catering to today are mind-boggling. Wait, I think I have diverted from my story, haven't I? Damn, I do this all the time, okay, back to the story.

I was testing this application for Payment Card Industry Compliance recently. I was quite impressed with the application at the outset. The application seemed to be loaded with some innovative features and it seemed like a great application for the business vertical it was hoping to address.

I started to test the application a few days later. It was sometime in the evening. I was not in the mood for any more testing. I had done quite a bit that day. I had already finished a preliminary vulnerability assessment of the server and as the assessment would be performed over a few days (yes, I procrastinate, a lot!), I thought of playing some Pacman. It is one of my favourite games. I thought of a slightly weird way to play it. The application I was testing was structured in a way where the user would use the input fields to enter values to be stored in the Database and as the Database updated, the previous inputs would be displayed in the table below it. Great way to test for persistent XSS, thought I. Therefore, I entered this harmless reflected XSS script alert in a field


and this is what I got


"Not bad", thought I, "the developers have managed to keep the bad apples out, or could it be the simplistic process of weeding out the angular bracket using a even simpler client side validation routine?"

Not to be deterred, I fired up my ever-trusty WebScarab and decided to take this attempt at killing two birds with one stone (namely me wanting to play Pacman in a different way and app sec testing) and caught a perfectly harmless request and gave it a interesting twist. I entered as input an html embed pointing to the Pacman Flash game, a lo I was gleefully playing Pacman on an application which had no business storing this in its Databases. One part of my test was done, quite a finding too. Cross Site Scripting (and later CSRF) vulnerabilities rampant on this site.

Coming back to my initial tangent. There are around 108 million distinct websites in the world today and even now, 23% of the world's population is exposed to the Internet, which is looking at a meteoric growth pattern in the future. According to the WASC (Web Application Security Consortium), almost 50% of web applications are vulnerable to Scripting and Information leakage vulnerabilities. As development becomes easier for everyone, we are only going to see more number of sites and apps falling prey to session hijacking, SQL Injection, Denial of Service and many other evolving attacks.

BTW, You can play the evergreen Pacman here

The Developer's take on Input Validation

I have a bunch of friends working in some of the most coveted Software Development companies in India. I met some of them in a coffee shop recently and we got talking about work (which is, unfortunately the only thing all of us for more than 12 hours a day). They were all working on a Relationship Management Application (web interface) which they were designing for a major European Bank. This Relationship Management Application facilitated the Bank's relationship managers to build stronger relationships with clients who were High Net Worth Individuals and keep them marveling at the bank's efficiency and Customer friendliness.

This application allows the bank's relationship managers to go over the client's account information. They have access to a client's transactions, his family information and other personal records as well. (I guess, by now, you can see where I am going with this)

Shamefully, I put my Security Hat on! ( I was in a coffee house with some friends!!), and I started to go "Auditor" on my buddies. I asked them what they were doing to validate data. The answer they gave me was this. "You see, this is not an Internet facing Application, the users of this application are the bank's staff. Why the hell would they enter some nonsense input like a '*' or a '<'. There is no real need to have this validation done, because it is a waste of time and more importantly, serious billing hours for us, because this is a Fixed Cost project and we had to deliver this application pretty quickly". For some of you who are not aware of a "Fixed Cost project", it means that this project is one where the cost of the project is fixed regardless of the amount of time and effort which is put in by the Software Development company undertaking this project. One more clue to this puzzle has been given, as you can see, the Software Development company my friends are working for doesn't really want to go beyond the scope of work and work out some validation routines for this app.

The next thing I asked them was whether their client had not asked them for validations to be built in as part of the application. They said that the client only required some basic client-side validation (which checks for if a field is empty or not) and that was that. Another clue in this relatively simple case my friends. There is only Client Side Validation and that too, a simple one!!

I did not display my shock that day to my friends sitting there with me and enjoying a nice cuppa, but I am shocked enough to say the following:

1. 61% of respondents think data leakage is an insider’s job. 23% believe those leaks are malicious. - McAfee and Datamonitor’s Data Loss Survey, 2007


2. When people are accessing client data worth millions of dollars, they better make sure that they validate inputs for more than checks for "empty fields".


3. Insiders have detailed information and a data leak from the inside can be debilitating for a company.
   


4. 'Cause you don't have to be a "Super-Hacker" to steal info from an application which validates input this way. Any insider with some basic HTML and Javascript knowledge can game this app.
   


5. When you are outsourcing application development, ensure that Security is your primary concern. Especially when you are a large Bank and when there is a data-leakage, you will probably lose all the customers you are trying to keep the happiest.
   


6. A Note to Software Development Companies: Your reputation will also be in the swamp if you allow your applications to have such issues. Validate input, it is not that difficult or expensive. It is much less expensive than a loss of credibility and reputation.