.gif) |
|
 |
| Application Security |
Many organizations realize that commercial off-the-shelf software cannot meet
all of their business needs. Therefore, they must develop their own applications,
either in-house or by outsourcing the development to contractors. Writing secure
applications, especially secure Internet applications, requires significant amounts
of security expertise, and in many cases, these custom applications can provide
significant exposure to risks.
The core problem is that there simply isn't enough information for developers on
how to write secure applications, specifically secure web applications. A quick
trip down to the local bookstore will reveal sixty books on network security, but
only one or two resources on securing web applications. In fact, a large portion
of the books on how to write web applications contain examples that actually
create security problems. This isn't a matter of how well someone knows how to
program... it's nearly impossible to write secure code without a proper understanding
of the security implications of the application.
A few examples:
Any security checks that are being performed on the client side of your web
application are nearly worthless from a security perspective.
For example, many organizations use JavaScript in their web applications to force
users to input data in a certain way. A form might ask for the customer's email
address, and use JavaScript to validate the email address. The problem? JavaScript
is executed on the client side, so a malicious attacker can simply ignore the
JavaScript and send bad data directly to your application.
If an attacker can insert even a few bits of malicious data into your web application,
they can often gain control of your entire site.
The vast majority of web developers
never adequately check the data that is coming in to their application. This is
mainly a result of programmers not being educated on the differences between writing
traditional GUI applications and writing web applications. When writing a GUI in
Visual Basic, for example, the programmer has much more control over what data is
returned from a screen. On the web, the programmer has absolutely no control over
what data comes back, so they must check the data each and every time. If an
attacker can manage to sneak in a semicolon, for instance, followed by a SQL
statement, they may be able to cause their SQL statement to be executed on the
database server. And since many organizations do not have adequate database
security , the attacker can most likely execute shell commands on the database
server, mail himself copies of all of your credit card numbers, or simply destroy
your database.
SSL doesn't have anything to do with securing your web application.
Secure Sockets Layer (SSL) technology is designed to encrypt traffic between your
users and your website. Once it has reached your website, it's identical to
plaintext web requests. If your application isn't secure to start with, encrypting
the traffic to it won't make it secure.
Firewalls have almost nothing to do with securing your web application.
Firewall restrict which types of traffic are allowed to your web server. They allow
HTTP (web) traffic to your web server, and hopefully drop all other traffic.
Unfortunately, the vulnerabilities that attackers are going to exploit on your
website are HTTP traffic, and firewall will allow them through.
Netbriar offers a number of services to help you not just secure specific web applications within your organization, but to help
your developers learn to write more secure Internet applications.
Application Security Assessment
Many organizations already have web applications deployed, and do not have a good
understanding of how well the application is secured. Netbriar's Application
Security Assessment consists of five phases:
- Penetration Testing: Identify externally accessible vulnerabilities within
the web application
- Source Code Review: Review the source code to the application to identify additional vulnerabilities
- System Environment Review: Review the configuration of the application server to identify vulnerabilities
- Reporting: Create a coherent view of the security vulnerabilities within the application, including what steps are necessary to resolve the vulnerabilities.
- Review and Education: Using the Application Security Assessment Report generated within Phase 4, meet with management and the development team to explain not only the impact of vulnerabilities, but how to prevent them from reoccuring
|
|
|
