Challenges Faced by Automated Application Security Testing Tools

With the growing number of online security threats and evolving nature of data breaches, the challenges involved in maintaining website security parameters keep advancing as well. For instance, if you download, run and install a product from a website and expect to get a report highlighting its vulnerabilities, you are probably wrong.

The right automated application security testing tools should be able to let you play around with the configurations so that you can adjust them for your website.

Here are some of the common challenges faced by application security testing tools:

Script Parsing

Flash, XML and JavaScript, all have come a long way since they were first introduced. They continue to become complicated, presenting a set of unique challenges when it comes to testing them for security.

Code isn’t as simple anymore. It now contains conditional behavior based on user preferences, website environments, dynamic links, etc. The download code is likely to change frequently depending on the function performed and the order of those functions as well.

Logical Flow

There are many websites that still require users to navigate in a certain order before enabling them to use a function. The right example would be the checkout page across most ecommerce websites.

Many websites still rely on crawlers that fetch a page, identify links and fetch them without the idea of actually filling a cart before checking out. These websites bring a set of unique challenges when it comes to testing them for security.

Sessions State Management

Perhaps some of the most complicated problems are faced in session state management. Websites use cookies and different tracking mechanisms to track user identity and activity. For vendors, this can be quite difficult considering that developers implement session tracking systems in their own way.

One common problem automated application security testing tools face is staying logged onto the website. When an attack is sent against application parameters it may end up logging out the tool. Another problem is when multiple requests for sharing a session token are sent simultaneously. They often invalidate themselves and you need to send them manually. The drawback of sending one request at a time takes up a lot of effort and might not be practical in some cases.

As the leading web application security and penetration testing service provider in Australia, we understand all of these challenges and work our way around them proactively.

Over the past years, we have helped countless number of clients stay vigilant, and safeguarded them from hacks and breaches. Get in touch with us to discuss your needs and find out how we can help.

Session Hijacking – What Is It?

There are many security concerns when it comes to client-side use of any web application just as there are for the business providing the online service. Session hijacking is just such an issue.

It is the malicious act of taking control of user session after successful generation or obtainment of an authentication session ID. Session hijacking typically involves use of captured, forced, or reversely engineered session Ids by the attacker. The goal: to take control of the session in progress from a legitimate user’s web application session.

Types of Session Hijacking

Session hijacking is split into two types, active and passive session hijacking. The main difference between these two types is the degree of hacker’s involvement in the attack. Another essential difference between the two types of session hacking are:

Active Session Attacks

The hacker finds and takes over an active session, i.e. the session is still in progress.

Passive Session Attacks

The hacker hijacks a session but sits back, observes and records incoming traffic.  

There are a number of ways user-side web application session token could be compromised. The most common are:

• Session sniffing
• Predictable session token
• Client-side attacks (Trojans, malicious JavaScript codes, XSS, etc)
• Man-in-browser attacks
• Man-in-middle attacks 

Following are some helpful techniques that can be used to avoid session hacking.

Side-jacking

SSL is used commonly to protect login pages by many websites today however applying a standard, unencrypted HTTP protocol after client’s authentication is also not a good idea. Why? Hacker can read the unencrypted HTTP traffic (passing between server and client) and steal its session cookie very easily. Of course the session hijacker must also have access to the same network as authenticated client’s or know/guess name of session cookie.

You must understand how this works and employ an effective strategy after consulting with Lean Security.

Network Security

Often the first and only line of defence against session hacking is network security. You know that all non-encrypted HTTP communications can easily be hijacked. Employ only trusted and reliable people for gaining access to oncoming and going traffic. This will significantly reduce the threat of session hijacking.  

Another issue online businesses must look into is client’s connection with vulnerable points such as public networks. Anyone can connect and capture communication on unprotected private WLAN access points. Effective steps must be taken to ensure all access and connection points are secure.

 Adopting a rigid and strict stance when it comes to your web application’s security is the only way forward. Session hijacking is an extremely grave cybercrime that adversely affects businesses and their reputations along with misuse of untold amounts of sensitive client data. Take the right steps towards better security by undergoing your web application through a security health check by Lean Security!

Performing A Web Vulnerability Assessment – Are You Making These Mistakes?

There are a lot of things that must be kept in mind when in the process of securing your network. Unfortunately, most network security processes don’t go beyond patch management and installing antivirus software! There’s a lot more that can and should be done when it comes to implementing network security i.e. checking configurations, troublesome and default configured hardware, and dealing with known issues in third-party applications. It is these processes that make up web or network vulnerability assessment.

Making mistakes is human nature however not paying attention to your web application’s security needs when performing web vulnerability assessment can become quite a costly error! We have outlines some of the most common mistakes made by in-house IT professionals and administrators when it comes to web application vulnerability assessments.

Learn from them and make your web application’s security your highest priority, in theory and practice.

Not Attending To Least Important Vulnerabilities

You will of course have some high-level vulnerability within the web application that is given highest priority by network administrators and in-house specialists.  Nothing is wrong in labelling particular vulnerabilities high priority as they can pose a direct and immediate adverse impact to your web application. The real issue lies with not paying attention to the low priority vulnerabilities. This automatically leads to unequal allotment of resources for all web applications and vulnerabilities.  

Network administrators need to search, identify and fix all web security vulnerabilities that can even potentially cause problems. What more does this include?

• Seemingly harmless marketing websites
• Intranet and portals
• Content management systems
• Web interfaces for all network devices

Expect Reported Vulnerabilities to Be Fixed Without Following Up

Following-up is really important especially if it’s for something as important as your web application’s vulnerability assessment report. Keep in mind: assessing or scanning vulnerability within a web application isn’t the same as fixing it! You developers likely won’t even know of the identified issues because management may not deem them important enough. Almost always management of any business has their own set of priorities which is given precedence over addressed or identified security issues.

In such a case, it’s a better idea to partner with developer and follow-up accordingly. This will make sure all identified and crucial vulnerabilities are remediated.  

Assuming a Secure Web Application Is Also Compliant

Contrary to popular belief, a so-called compliant termed web application security assessment doesn’t necessarily make a web application secure and vice versa. Why are compliance and security not the same? Quite simply, compliance in website applications is merely a guideline of how a particular security program meets specific security requirements.

Compliance managers and auditors should sit down together and make sure all known risks are removed by making a website security plan based on requirements set by chosen security program.

Web application is indeed an important aspect for many business’s IT compliance programs. As such, you must hire the best third party managed service provider in your city. Consider signing up for Lean Security’s free trial.