We have security policies and practices and have a firewall in place. Are we still exposed to application level hacking? What are the components in a typical eBusiness security solution? Skilled developers build our Web applications. Do we still have security exposures? My site uses encryption for all sensitive data. Do I still need AppScan? What types of hacks does AppScan test for? What is SQL Injection and does AppScan test for it? What is Cross-Site Scripting and does AppScan test for it?

We have security policies and practices and have a firewall in place. Are we still exposed to application level hacking?

Yes. Security policies, firewalls and encryption are not effective against application level hacking. A hacker using a regular Web browser will easily pass through the firewall and encryption and send requests to the application. These requests are one of three types: Legal requests, which the application recognizes and accepts Illegal requests, which the application recognizes and rejects Other TThe third type is the most dangerous to the application because it represents a gray area that hackers use to probe an application for security weaknesses. This gray area is the reason why firewalls and policies are not enough to ensure protection. Back to Questions

What are the components in a typical eBusiness security solution?

Sanctum recognizes four layers of Internet security in a typical eBusiness environment: Desktop - anti virus tools Transport - data transport protection mechanisms such as SSL, PKI and other encryption methods Network - network protection measures like firewalls and intrusion detection. Application - application level defense such as access control and application firewalls. Also, today's site audits, which focus on the network level, will be augmented by application level audits. Back to Questions

Skilled developers build our Web applications. Do we still have security exposures?

It is imperative that programmers develop an awareness of and proficiency for eliminating security defects during the design and development of Web applications. This practice is proven to reduce security testing and patch costs downstream. More importantly, secure code one of the best defenses against getting hacked. Nevertheless, security defects inevitably make it through this process without an automated unit testing tool and, if not detected prior to deployment, end up exposed in production. AppScan DE integrates into the development in order to verify the application validates data effectively in order to ensure problems are solved early in the process. Back to Questions

My site uses encryption for all sensitive data. Do I still need AppScan?

can be reasonably sure that data passing from or to the site cannot be intercepted and used for malicious purposes. Likewise, web site administrators can store data in encrypted form so that if accessed directly, this information is indecipherable and useless. However, many web application vulnerabilities stem from flaws in application logic rather than in the openness of the communication between user and site. As a result, encryption is insufficient to prevent the effective exploitation of most application vulnerabilities. AppScan DE on the other hand, is a product designed to assess the security of the logic built into the application behavior. With both systems in place, a web site can rest assured that the odds of a successful hack have been substantially lowered. Back to Questions

What types of hacks does AppScan test for?

AppScan DE explores applications looking for vulnerabilities like a hacker would. Following is a list of many of the vulnerabilities AppScan DE finds and tests: SQL Injection Hidden Field Manipulation Parameter Tampering Stealth Commanding Forceful Browsing Backdoors and Debug Options Cookie Poisoning Cross-Site Scripting Buffer Overflow HTTP Attacks Suspicious content The actual number of tests AppScan sends to an application depends on the logic and structure of that application. In one example, on an application with 100 links, AppScan created and sent over 4,000 different tests. Back to Questions

What is SQL Injection and does AppScan test for it?

Web applications commonly use SQL to add, edit, or retrieve data from a database. If an application is not sufficiently protected from this form of attack, a hacker can inject SQL commands into a form field and have the backend database execute them. The destructive potential for this attack is enormous. SQL injection can enable a hacker to: Obtain any or all of the information stored in the database Erase records Bring down the database AppScan DE runs a series of tests during a scan to determine if the application is vulnerable to SQL injection. It does this safely to ensure that the integrity of the database and its contents are not compromised. Back to Questions

What is Cross-Site Scripting and does AppScan test for it?

A Cross Site Scripting (XSS) attack is one wherein an attacker lures a victim (client of a web site) to send a maliciously crafted request to the vulnerable site. As a result, the victim's browser will execute a malicious code (typically Javascript) sent by the attacker. This code can then send the attacker private information that is in use by the victim with the vulnerable web site. Such information can be account credentials, cookies, and site-specific sensitive information. An XSS attack is therefore an attack against the privacy of the victim, who is a client of the vulnerable site. The attack does not run malicious code on the vulnerable web site - rather, it uses the flaw in the web site to force the victim's browser to execute Javascript (or similar language). It also means that the victim does not run malicious native code, but rather a Javascript (or similar) code confined to the browser and to the context of the vulnerable site. AppScan DE runs a complete series of tests against every application to determine if it is susceptible to this popular type of attack. Back to Questions

AppShield, AppScan, Policy Recognition, and Adaptive Reduction are trademarks of Sanctum, Inc. All other product names referenced are the property of their respective owners and are hereby acknowledged.