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!!!!"

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.