Web apps vulnerability: Why & how to protect – The Basics

Businesses are concerned with the problem of penetration into their using web apps by unauthorized persons. Organization uses applications to provide better service to customers. But if these apps are compromised by unauthorized code then the business loses integrity.

Now a day, it is our big concern to protect our business apps from being compromised. The first step is to understand how and why apps are compromised.

Why the web apps are vulnerable?

Web codes are mainly HTML. HTML is a clear text language which is visible to anyone by visiting the sites. Hackers can easily modify the code and add functionalities that either act differently or obstruct existing functionality.

Hackers can penetrate code in the following ways:

Injection: The attacker injects malicious code into the web code. This malicious code is written to extract information from the client’s computer or device for unscrupulous use.

Cross Site Scripting (XSS):  Hacker inserts a script into the code that is run at the client’s site. This script may be for extracting information or providing misinformation in order to undermine competition.

Identity Theft: Here the attacker assumes the identity of the user and accesses important or sensitive data. The hacker then can use this data to cause inconvenience or loss to the user.

Direct Object Reference: This type of risk occurs when objects such as tables within a database are directly referenced in the URL. The hacker can use this object to access related objects within the database.

Insecure cryptography: Sensitive data such as credit card information, bank details, SSN etc. may be hacked by corrupt persons if they are stored, or travel over the internet, encoded in a simple and easy to break code.

Insufficient Layering: Applications that do not encrypt and decrypt data or authenticate users, or check certificates, may be used by hackers to gather personal data of the users.

How to avoid these risks

The above list is not full but does cover some major areas of vulnerability. Developers, web designers, SQA/Test staffs can counter these vulnerabilities by being aware of them and including code that will look out for malicious code.

Basic Security Practices for Web Applications:

• Applications use data entered into forms to access databases. If this data is validated before accessing the database, injections can frequently come to light. Proper validation can also detect malicious scripts entered into the code.

• Coders must assume that any data entered by users is untrusted. All inputs must be validated before use. Checking for type, length, format, and range are the common ways in which inputs are validated.

•  Identity thefts and broken authentications can be prevented by forcing a user to re-login even though he has not explicitly logged out. When a user logs in to a site an id is created. If this id is created using a predictable formula then hackers can pinch that identity and resend it to access client information. Generating random id is the best way to avoid risks of identity thefts.

• Randomizing ids can also mitigate attacks due to direct object reference. In fact, databases should never be directly accessed by user entered data. Applications should validate and clean data before accessing databases.

• Most importantly, the infrastructure used to run applications including hardware, software, OS and other components must be secured.

 So, we need to concern about above listed practice to avoid vulnerability of our business apps.  

How can World Wide Web sites be tested?

Web sites are essentially client-server applications - with web servers and 'browser' clients. Consideration should be given to the interactions between html pages, TCP/IP communications, Internet connections, firewalls, applications that run in web pages (such as applets, javascript, plug-in applications), and applications that run on the server side (such as cgi scripts, database interfaces, logging applications, dynamic page generators, asp, etc.).

Additionally, there are a wide variety of servers and browsers, various versions of each, small but sometimes significant differences between them, variations in connection speeds, rapidly changing technologies, and multiple standards and protocols.

The end result is that testing for web sites can become a major ongoing effort.

Other considerations might include:

• What are the expected loads on the server (e.g., number of hits per unit time?), and what kind of performance is required under such loads (such as web server response time, database query response times).
• What kinds of tools will be needed for performance testing (such as web load testing tools, other tools already in house that can be adapted, web robot downloading tools, etc.)?
• Who is the target audience? What kind of browsers will they be using? What kinds of connection speeds will them by using? Are they intra- organization (thus with likely high connection speeds and similar browsers) or Internet-wide (thus with a wide variety of connection speeds and browser types)?
• What kind of performance is expected on the client side (e.g., how fast should pages appear, how fast should animations, applets, etc. load and run)?
• Will down time for server and content maintenance/upgrades be allowed? how much?
• What kinds of security (firewalls, encryptions, passwords, etc.) will be required and what is it expected to do? How can it be tested?
• How reliable are the site's Internet connections required to be? And how does that affect backup system or redundant connection requirements and testing?
• What processes will be required to manage updates to the web site's content, and what are the requirements for maintaining, tracking, and controlling page content, graphics, links, etc.?
• Which HTML specification will be adhered to? How strictly? What variations will be allowed for targeted browsers?
• Will there be any standards or requirements for page appearance and/or graphics throughout a site or parts of a site??
• How will internal and external links be validated and updated? how often?
• Can testing be done on the production system, or will a separate test system be required? How are browser caching, variations in browser option settings, dial-up connection variabilities, and real-world internet 'traffic congestion' problems to be accounted for in testing?
• How extensive or customized are the server logging and reporting requirements; are they considered an integral part of the system and do they require testing?
• How are cgi programs, applets, javascripts, ActiveX components, etc. to be maintained, tracked, controlled, and tested?
• Pages should be 3-5 screens max unless content is tightly focused on a single topic. If larger, provide internal links within the page.
• The page layouts and design elements should be consistent throughout a site, so that it's clear to the user that they're still within a site.
• Pages should be as browser-independent as possible, or pages should be provided or generated based on the browser-type.
• All pages should have links external to the page; there should be no dead-end pages.
• The page owner, revision date, and a link to a contact person or organization should be included on each page.