Web application or site security need, resolution plans

Web application vulnerabilities are now the most prevalent at more than 55 per cent of all server vulnerability disclosures. This figure doesn’t include vulnerabilities in small scale custom-developed web applications, so it may be just the tip of the iceberg. This write up is all about understanding how to quickly find and fix vulnerabilities in web applications. The goal is to prevent attackers from gaining control over the application and obtaining easy access to the server, database, and other back-end IT resources.

Let's start with what actually matters in Web Security, as the world embraces cloud computing, more and more people are transacting business, conducting research, storing information, collaborating with co-workers, publishing personal thoughts, and fostering relationships via web applications.

These web applications use a simple architecture:

• Internet or an intranet for connectivity between user and application
• Creation of the application with a browser-rendered markup language such as hypertext markup language (HTML)
• Hosting of the application in a browser-controlled environment
• A browser for user execution of the application on an endpoint device

Each time you launch a browser and connect to a website, you’re using one or more web applications. These enable thin client computing, which dramatically reduces resource requirements for the endpoint device. With web applications, the bulk of processing occurs on servers located at remote websites. As a result, users can run sophisticated web applications from virtually any PC, a low-powered netbook, a tablet computing device, or smart-phone. Web applications are generally easy to use, cost little or nothing for the user to operate, are efficient, and pervasive. As you’ll see, web applications hold the same attraction to modern cyber criminals because web application vulnerabilities are now the most prevalent of all server vulnerability disclosures. Network security professionals are already familiar with many other types of IT vulnerabilities. The process of finding and fixing these is called ‘vulnerability management’. Let's quickly discuss the understanding how to quickly find vulnerabilities in organization’s web applications and fix them so as to prevent attackers from gaining control over the application and other IT resources.

Gaps or Entry Points for criminals: Vulnerabilities in web applications may take dozens of forms. Many attacks use fault injection, which exploits vulnerabilities in a web application’s syntax and semantics. In simple terms, an attacker manipulates data in a web page Uniform Resource

Indicator (URL) link to force an exploitable malfunction in the application. The two most common varieties are query / SQL injection and cross-site scripting. Later we’ll dive into details of how these and other vulnerabilities work (and how to get rid of them!). For now, here’s the basic idea. Consider a typical URL:

http://My_example/Zxx.cgi?a=1

Executing a SQL injection exploit simply requires modifying the URL. All that’s needed might be one odd character to trigger a successful exploit, such as adding an apostrophe to the end of the URL:

http://My_example/Zxx.cgi?a=1'

The ‘successful’ outcome can give an attacker control over the application and easy access to the server, database, and other back-end IT resources. Needless to say, this access can trigger disastrous results.

Data is the object of desire for attackers – particularly data that converts their efforts into cash. The most lucrative source of this data is a business database containing information that can be sold or used directly by an attacker for profit. Business databases are like pots of gold brimming

with bankable opportunities – all in one location.

Confidential customer data may be the highest value data because it’s easy to sell and leverage. It includes personally identifiable data such as names, addresses, birth dates, payment card Primary Account Numbers, email addresses, and so on. Some of the worst data breaches have included the theft of millions of records containing this information. The massive scale of instant damage is unprecedented.

Web application attacks may also target individuals, one by one. Some attacks are executed by infiltrating a trusted website, which then injects malware into computers used by unsuspecting visitors. The malware might redirect links to rogue sites that steal personal information directly from the user’s PC. It could trick users into revealing confidential passwords or payment card data. It may even hijack the user’s PC and transform it into a spam server or other nefarious mechanism aimed to further the attacker’s goals. Either way, successful attacks on web applications can result in highly negative fallout. The rest of all related losses are paid by the payment card companies. If the data allows a criminal to access other accounts or steal a consumer’s identity however, financial fallout could be severe for that individual. Resolving just one incident of a stolen identity may take years of effort. Personal fallout would be catastrophic if multiple breaches at different merchants occurred during a short period of time.

Way of improvements: Web application vulnerabilities are often outside the traditional expertise of network managers, even if their main job is network security. The built-in obscurity of web application vulnerabilities helps them evade traditional network defenses unless an organization takes deliberate countermeasures. Unfortunately, there’s no silver bullet for detection! As with network security, the best strategy is a multi-layer approach.

Detection and remediation may require source code analysis. Detecting some web application vulnerabilities may require on-site penetration testing.

The good news is that most prevalent web application vulnerabilities can be easily detected with an automated scanner. As you’ll see later in this book, scanning web applications acts to supplement and compliment manual testing by performing likely attacks on target applications.

Scanning web applications has even become a strategic requirement in some regulations. For example, the Payment Card Industry Data Security Standard (PCI DSS) version 2.0 now requires all merchants accepting payment cards to pass quarterly scans for vulnerabilities in web applications.

• Automated scanning can provide many benefits, including:
• Discovering and cataloging all web applications in your enterprise.
• Lowering the total cost of operations by automating repeatable testing processes.
• Identifying vulnerabilities of syntax and semantics in custom web applications.
• Performing authenticated scanning.
• Profiling the target application.
• Ensuring accuracy by effectively reducing false positives and false negatives.

We need to understand how scanning and other tasks fit into a vulnerability prevention program (we call it VPP in our organization) which addresses everything it takes to develop, deploy, and maintain secure web applications, and that’s exactly what we discuss.

Cross-discipline cooperation is mandatory for web application security. It’s vital when time is of the essence for urgent vulnerability remediation. So decide now who’ll take the lead as doing so will help to smooth out operational issues later. I normally suggest that overall responsibility for web application security should rest with the security team (a nominated approach not a designer / architect team). He / she / these people are responsible for vulnerability management in networks and systems. Adding application security to their watch makes sense because this team already has ‘find and fix the vulnerabilities in its DNA and workflow. Integrating the use of automated scanning tools for web applications augments the technical skills of security staffers doing vulnerability management. There are various tools which can guide the security team as it guide the development teams. Remediation details can remain the domain of web application programmers.

An organization that relies upon custom web applications to implement business processes can have up to thousands of web applications. These may include full-blown applications, or consist of modules from login pages, forms, card payment / transactional scripts, shopping carts, and other forms of dynamic content. Those that appear in your network could be developed in house, although some may be legacy sites with no designated ownership or support.

Analyzing all of these for vulnerabilities and prioritizing their importance for remediation can be a huge task without organizing efforts and using automation to improve efficiency and accuracy.

The software development lifecycle (SDLC) aims to do this analysis and prioritization. SDLC is rooted in the mature discipline of Software Assurance, which the industry defines as follows: ‘Confidence that software, hardware and services are free from intentional and unintentional vulnerabilities and that the software functions as intended.’ (Source: Software Assurance Forum for Excellence in Code.)

The Secure Development phase is all about building security into web applications right from their inception. This is what commercial software companies do because customers expect what they license to be secure. This isn’t an automatic process, however, so as your organization strives to be smart with its efforts to secure applications on its websites, it needs to provision for several elements. Like Secure development , web applications are deployed when deemed functional within specifications, and when they’re secure. Upon deployment, ensuring their security requires two new elements: Vulnerability Scanning & Penetration Testing. The comes to securing all transactional details like Secure operations for this we need to incorporate tools like Web Application Firewall & Activity Monitoring. For the topic of vulnerability management, there’s no lower or higher rating of importance ascribed to web application scanning versus other kinds of scanning such as for network or system vulnerabilities.

Creating web application security requires your organization to scan for all these types of vulnerabilities because they’re interrelated. Security in each category can suffer from weaknesses in other categories. This is why comprehensive vulnerability management is essential.

I will stop here now I have realized that there are much more to be discussed / written on this topic this is just a start. I will try to me proactive in writing next chapter on this. I will love to listen to you on your take / any suggestions for me please shoot them at ravindrapande@gmail.com.

Swaha - idam n mama – The meaning I believe

Let’s think about our for father traditions. During rituals known as Shraadh, Hindus worship the ancestors or the Pitr(forefathers / grandparents ) . This is a specific process, reverence is reserved for three or more generations of ancestors – the father, the grandfather and the great grand fathers etc. Generations before this are referred to as “the others”. It is almost as if, after three generations, the family is expected to forget even the name of that ancestor. It is the final letting go.

The notion of swaha (letting go) is central to Indian thought and plays a key role not only in Hinduism but also Buddhism and Jainism. One is constantly asked to move on. That is why, traditionally in India, no tombs were built. The body of the deceased was cremated and the ashes thrown in rivers as one hoped for a quick journey across the river Vaitarni to the land of death followed by a quick rebirth.

Tombs were reserved for those who lived exceptional lives that liberated them from the cycle of rebirths. These tombs were known as “Samadhi” and often contained the relics of holy men, such as the Buddha and various Vedic teachers who had attained liberation or moksha.

The ordinary man was encouraged to move on after death and not cling to memories. Memories were seen as fetters to intellectual and emotional evolution. They conditioned the mind and created impressions that trapped the soul in the cycle of rebirths. For a culture that valued the soul over the flesh, memories were seen as something temporal, something limited to space and time that one had to transcend. This is why history, or at least what is conventionally understood as history, played a very poor role in Hindu thought. More important than kings and events were ideas. And ideas were recurring. Which is why itihasa meant not just history but ‘what was, what is, what will be’ aligning itself to the concept of sanatan, the eternal truth, which forms the core of Indian thought.

What mattered more to Hindus, Buddhists and Jains were eternal principles, not time-bound details. What matters more than the particular is the universal. More important than an Alexander who conquered most of the known world or Ashoka or Aurangazeb who ruled most of the Indian subcontinent, was the mythic idea of the Chakra-varti who ruled the universe, only to realize its futility.

This disdain or indifference for history perhaps stems from faith in rebirth. If this life is but one of infinite lives, then how do events of this life matter. What matters is reflection, introspection of how eternal principles keep manifesting and recurring in each lifetime.

Contrast these with the worldview of the Greeks and the Chinese and the Arabs and the Mongols and the British. Each of them believed in one life. And so this life mattered. The events of this life mattered. And so had to be recorded carefully. History was thus born. And so were tombs. Monuments to the dead had to be raised. In the Mahabharata, there is a derisive reference to ‘worship of a collection of bones’ in the Kali Yuga. Clearly, this celebration of the past was not appreciated in Vedic thought.

Indian disdain for history is most evident when one watches historical films and teleserials. Even a slight deviation in a mythological serial can shut the country down but no one cares when historical characters are subjected to flights of fancy. History plays second fiddle to legend. What matters more is entertainment and romance. Nobody cares what actually happened when Alexander came to India, what matters more is how he reacted to the royal nobility of Porus. Nobody cares what really happened to Prithviraj Chauhan but everyone cares about how he married Sanyogita and killed Muhammad Ghori. It must be remembered that it took a British film maker to make the first Indian film on Gandhi. Later Indians did make films on Babasaheb Ambedkar and Sardar Vallabhai Patel but their poor show at the box office is testimony to the value Indians place on history.

This is why, in India, when one goes to the village, people will know less about people who resided in the village a few generations ago but more about the land’s relationship to Ramayana and Mahabharata. Thus, there are ponds across India where Ram bathed and caves where the Pandavas lived. The same awe is rarely reserved for structures built by parents before great grand parents.

The practice of recording family trees does exist in a few communities, especially in Rajasthan and has been seen as a practice brought down by Huns and Scythians who settled in this region post the Greeks. Another place where family trees are recorded are in pilgrim spots where the local priests known as Pandas claim hereditary rights to serve members of a particular clan, such as kula or gotra. But by far, history is treated with indifference. In fact, had the Greeks and Arabs and Chinese not recorded their interactions with India, much of Indian history would have gone unnoticed.

When one reads sacred literature, one finds long genealogies of kings that trace their origin right up to the gods. There are as many genealogies as there are scriptures and there are widespread variations between them. Scholars have tried hard to put together a history of India based on data found in the Puranas and have failed. The purpose in these lists is not so much as being accurate as it is about connecting the patron of the scripture to one of the two line of kings that ruled India since mythic times, the Surya-vamsis or the sun dynasty or the Chandra-vamsis or the moon dynasty. Even today, most Rajput royal families claim descent from the sun, while many royal families in the East and South claim descent from the moon. The genealogies thus supported the ‘divine right of kings’.

But the British put us on the defensive, forced Indians to construct history. They made Indians feel inferior because they had no sense of history. They went about writing the history of India. And what they wrote, divided Indians forever.

Today, we have a Left-wing view of history that ignores, even mocks the faith of Indians. And then there is the Right-wing view of history that rejects all ideas that came from the British and insists that everything in India is much older than any historian can ever imagine.

With the British came a chronology of India: the Indus Valley civilization followed by a Vedic age followed by Buddhism then the Greeks, then the Huns and Gujjars, then the rise of temples followed by the arrival of Arabs and Mongols and finally the Europeans. In this scheme of things, holy epics like Ramayana and Mahabharata are recorded in the post-Buddhist period, while the more abstract Vedas come from the pre-Buddhist period. In the British view of things, Vedic thought is not indigenous, it came from elsewhere. This becomes a double whammy for the traditional mind. It suggests that the most revered Indian ideas are not only rather recent but worse, foreign!

All these findings upset many Indians as they seemed to be strategically motivated to make Indians feel inferior. So there has been over the past 100 years of retaliation. The baby was thrown out with the bathwater. All datings were rejected. Everything has to be older to be genuinely valued. So everything from Ramayana to Mahabharata to Bhagavad Gita is taken to come down from a time long before Alexander, and long before the Indus valley, and all from the Gangetic plains.

In the din of arguments we will never know the truth. Epigraphic and archeological evidence can never give the full picture whereas faith will always be inflated by imagination. If one follows the ancient Vedic route of not focusing on details of events and seeking the underlying idea, one discovers something very interesting in this debate over Indian history. One discovers that the past is a powerful way to intellectually dominate a people. The British did it by insisting that what Indians believed to be history is actually myth and by myth they meant ‘falsehood’, not ‘subjective truth’. Indians have retaliated by insisting that ‘subjective truth’ is ‘objective truth’. And hence all holy books in India, as far as the devotee is concerned, came together at least 5000 years ago. Today the fight between faith and history has affected school curriculum and court judgments. While many assume this is a fight for truth, it is, in all probability, simply a fight for self-esteem. And this is more than five thousand year old as mentioned in various granths in our culture.

Would love to receive your thoughts on this at Ravindrapande@gmail.com

iPhone development part 1

Let’s take a detailed took at the landscape for iPhone development, enumerating the different ways to build iPhone Apps and also the tools available to help in the same. iPhone is the biggest thing to happen to the mobile world in real times. The amazing screen and other browsing features has made the Apple iPhone the most popular web browsing mobile device. The same features have also resulted in developers salivating over an opportunity to create iPhone Apps. We first discuss the two fundamental ways to build iPhone Apps and point you to important resources which will help you get started on them as soon as possible.

Basically there can be two different ways that you can write applications for the iPhone:
1. Web Applications (work via browser & networks)
2. Applications (phone based can be network independent for our current understanding)

Web Applications are applications that run of the Safari browser on the iPhone. These applications are typically web applications with their interface and layout customized to suit the browsing communications that have emerged for the iPhone.

I use the word “communication” s specifically to emphasize the fact that web applications need to not only change the layout and appearance to suit the iPhone, but also at the same time rethink usability (not design) to suit the new browsing patterns that have come with the iPhone.

Let’s discuss more on these “Web Applications”

As previously mentioned iPhone Web applications are essentially web applications which run of the Safari browser on the iPhone. The major difference from native web applications is that they cannot access the hardware features like accelerometer, file system etc. They are constrained to run in the sandbox of the browser which is similar to other web applications.

The easiest way to build iPhone web applications is to take your existing web applications and fix the layout so that they match the layout guidelines on the iPhone. The biggest change that this would require is to reduce your real estate to match the size of the iPhone. Also the navigation and usability needs to be changed to better suit the iPhone usability idioms.

The biggest usability change that can be seen in iPhone web applications is the streamlining and extreme focus that it has bought to existing web applications. Instead of the typical web pages which are crammed with content, navigation, lists, advertisements, promotions in every nook and corner, iPhone web applications need to be extremely streamlined and focussed in their approach.

This streamlining and focus is achieved with categorizing every page into only two different kind of layouts. These layouts are firstly a list based layout and secondly an action based layout. What this means that any existing web application need to be broken down into independent screens, each of which need to be either a list based screen or a single action based screen. This is apart from the additional navigation which can be provided in the form of a Next/Previous buttons in the top bar or a tab based navigation.

There are already a lot of tools which help you convert your existing web applications into iPhone applications. Below we mention two of them which probably might be the only thing you need to build iPhone web applications.

Applications are applications that are run on the iPhone itself. These applications are developed largely in Objective-C (a variant of the popular C language) and use the iPhone specific features which are exposed using the Cocoa API on the iPhone.

Obviously, as native applications run directly on the iPhone they have much better access to the iPhone hardware and can use them effectively. And exclusively the iPhone hardware dependant.

Phone applications are applications which run directly on the iPhone hardware. These applications can take advantage of the wide range of hardware innovations that come with the iPhone. These include support for multi-touch, hand gestures, iPhone camera, accelerometer and the built in GPS.

However phone applications are much harder to build as compared the web applications. And if you are not too much into programming the complex syntax of Objective-C will present to you a very steep learning curve. On the plus side, those who have scaled this curve can use their programming chops to cook up some of the most innovative applications that are getting enabled by the iPhone. Add to that the instant recognition and money that a lot of developers have earned by listing on the iPhone App store, and that should be motivation enough for you to start hacking right now.

Native applications unfortunately require you to invest in Apple hardware if you don't already have some. At the minimum you would need a Mac because the iPhone SDK currently only runs on one. Secondly, you would need an actual iPhone. Even though the SDK comes built in with an iPhone simulator this is not enough because a lot of features don't run the same as on an actual iPhone. Case in point is the accelerometer and multi-touch support both of which are not supported on the emulator.

There essentially two big pieces of technology you need to master to build iPhone native applications: Cocoa and Objective-C.

Cocoa is the platform and the API that iPhone exposes for you to access the low level iPhone functionality. Apart from this Cocoa also provides the infrastructure to build simple form based applications for the iPhone. As Apple provides exhaustive documentation on the Cocoa API it is pretty straightforward to get started on.

Objective-C is the variant of the popular C language which is used for the iPhone development. Objective-C is pretty much the same as C/C++ apart from the way it structure functions and message passing. Message Passing, or the way Objective-C structures functions calls are a much more object oriented way of programming, however the syntax takes some time to getting used to. Apart from Cocoa and Objective-C in case your native application is graphics heavy (for example games) it might need to use Open GL to build the graphics part. Open GL is an open source graphics library and is supported on the iPhone.

I believe this is more than required for theory now lets dwell more on how to implement this. So next step we will understand about creating a simple iPhone / iOS application.