Developing secure Web applications: An introduction to IBM Rational AppScan Developer Edition

This article focuses on the role developers should play in improving Web application security, and details how IBM® Rational® AppScan® Developer Edition enables them to do so. Rational AppScan Developer Edition is the first to offer all of the dominant security analysis technologies in one product (dynamic analysis, static analysis, runtime analysis, and string analysis), and is the first to tap into the potential of using these techniques together (composite analysis).

Share:

Guy Podjarny (guypo@ca.ibm.com), CISSP, AppScan Product Manager, IBM

Guy Podjarny is the AppScan Product Manager and a Senior Security Analyst with IBM Rational AppScan. Guy came to Rational through the acquisition of web application security and compliance leader Watchfire in July 2007. Guy joined Watchfire in 2004 bringing with him several years of senior product development and web application security expertise from previous roles including Sanctum.

In his role Guy is integral to the development and evolution of the company's market leading AppScan solution. He is also closely involved with researching and evaluating technologies and helping define and influence strategic directions for Rational's security solutions, and is a key contributor to Rational's Security Research group.

Guy has spoken at security events including ISACA, OWASP Chapter Meetings and others, participates in industry working groups and has contributed to several whitepapers and articles on application security.



16 September 2008

Also available in Chinese Russian

What are the challenges?

The main challenge is that vulnerabilities are all too common in today's Web applications. An example of this is security holes in a Web page's code that can allow an online banking client to see another client's data. The vulnerabilities can let hackers run queries on the application’s back-end database, and possibly take over the Web server itself. Web application security issues are an imminent and growing threat, and they are caused primarily by security bugs in the application’s code.

Another challenge is the cost of the late discovery of these issues. Most organizations leave the discovery of Web application security issues to a dedicated security team, which tests the applications before they go live. Fixing the found issues then requires a full iteration of late code changes by development and quality assurance testing personnel. This results in a very high cost to fix what is often the simplest security bug.

In addition, security experts are far outnumbered by developers. The security teams struggle to cope with the pace of new and changed applications. This usually results in only the most critical applications being tested. Others get posted with a high likelihood of security issues, because no security testing has been performed on them.

This situation is becoming graver, because Web applications play a growing and ever-more critical part of most businesses. The impact of breaches and hacks continues to grow, and yet security is not properly prioritized as part of the development process for these Web applications.

Solving this problem requires the participation of all of the different teams involved in the Web application development, but primarily the development and quality assurance teams. In the end, the underlying cause creating these issues is that unsecure coding introduces volumes of security vulnerabilities in Web applications. This article focuses on the role developers should play in solving this problem, and details how IBM® Rational® AppScan® Developer Edition enables them to do so.


Developers and Web application security

To get development to start testing for and remediating security issues, your team must first acknowledge the difference between your development and security teams. The technology available today is mainly designed for security professionals, and does not always meet the needs and use cases of development.

Table 1 provides some examples of the difference between the teams.

Table 1. Roles and responsibilities
Security teamsDevelopment teams
Security is their primary job. Delivering software is their primary job: security is one of many requirements.
They test applications with the goal of certifying that they are secure, and therefore attempt to find all of the problems in an application. They test applications with the purpose of finding the easy problems early, not for certifying. They do not have to find all of the problems.
If an issue is hard to understand or likely to be falsely reported (a false positive), they will usually spend the time to understand it, because it might pose a security risk. If an issue is hard to understand or likely to be falsely reported (a false positive), they will ignore it to avoid wasting time.
They deal with complete applications, with the full functionality included. They deal with partially developed applications.
They test many different applications only for security problems: they do not necessarily understand each application very well. They test one (or a few) applications for many different problems: they do not necessarily understand security very well.
Each audit is usually done by only one (or very few) auditors. Each application is usually developed by multiple (often many) different developers.

Because the two groups are not the same, the products designed for each group should be different too. Just as Rational AppScan Standard Edition is designed for security auditors, Rational AppScan Developer Edition is designed for developers, with their specific use case in mind:

  • It is designed to be another development tool, not another flavor of a security tool.
  • The product design favors ease of use and easy integration into the development tools and process over advanced security drill-down functionality.
  • It minimizes false positives and makes results easy to understand as a higher priority than increasing the breadth of a scan: this helps developers uncover issues early only as long as it saves time.
  • The included manual explore-based scans and static analysis functionality allows for easy testing of specific sections of the application that are known to be working.
  • The design makes repeated scans and configuration reuse for each application easy.
  • Collaboration and sharing of configuration and results are core parts of the product.

How security scanning works

Web application security scanning can be done in many different ways, but there are two dominant approaches that are the most widely adopted:

  • Dynamic analysis is the practice of testing the running application from the outside. This approach interacts with a running instance of the application, effectively attempting to perform light hacks (mostly harmless) to identify security holes.

    Dynamic analysis is similar to using a Web browser to step through a Web application, placing single quotes in every form field, and looking for SQL errors (which usually implies SQL injection exists) in the response.
  • Static analysis is the process of looking at the static application code and binaries, building mathematical models of how they work, and identifying security weaknesses by analyzing those models.

    Static analysis of code is similar to an automated code review, in which you try to mentally consider different types of scenarios, and understand from the code how the application would react to them.

A third analysis technique, called runtime analysis, monitors the running application as different events occur, collecting information about the code that got executed, the system calls performed, and many other factors. Runtime analysis is not really a standalone technique, but rather a way to improve dynamic and static analyses.

Rational AppScan Developer Edition includes all three analysis technologies, running them side by side and using each to bolster the other. Running them in parallel leverages the strengths of each technique, and using them symbiotically helps overcome their weaknesses, too. This article examines these approaches, and discusses how you can combine them into an effective solution.


Dynamic analysis

Dynamic analysis involves testing a Web application as a closed entity, interacting with it through its official interfaces (primarily HTTP). This activity is often referred to as Black-Box scanning, because it does not have or require visibility into what happens within the application. Dynamic analysis is the predominant approach to Web application security testing today. Rational AppScan Standard and Enterprise Editions are examples of dynamic analysis tools.

Dynamic analysis works in a way very similar to the one a hacker would employ when attacking an application. It is performed in two phases: Explore and Test.

The Explore (or Discovery) phase includes traversing the Web application as a normal user would, identifying the pages, form fields, and other inputs to the application. This exploration is done either using an automatic spidering engine, or by observing a user manually browse the site.

The goal of this step is to learn as much as possible about the application, the different components in it, the inputs it receives, and how it behaves when used in a legitimate manner.

In the Test phase, the scanner will repeat the actions seen during the Explore phase with a variety of modifications, designed to uncover vulnerabilities by submitting unexpected inputs. The application’s responses are then analyzed to determine whether an issue was indeed uncovered.

Some of the advantages of dynamic analysis include:

  • Discovery of the most critical issues: Since dynamic analysis tests the application as a hacker would, it finds the issues most likely to be discovered by attackers. These issues are the problems that you should fix first.
  • Low false positive rate: Issues are proven, because the tests are performed on a running application. There is no doubt that the application reacted the way it did, and the deduction that this implies that vulnerability does exist is usually quite accurate.
  • No requirement for source code: No source code is required, so this supports scanning of commercial off-the-shelf (COTS) applications, outsourced applications, machine-generated code, and other third-party components where code is not available.
  • Server-side-technology transparency: Testing from the outside allows dynamic analysis to be server-side-technology-agnostic, and hence be used for practically any Web application platform and language.
  • Very few prerequisites: You can perform tests with as little as remote access to a working Web application, and preferably login credentials.
  • Code, integration, and infrastructure testing: Dynamic analysis uncovers issues whether they are in the custom code of the application itself, in the integration of different components, or in the underlying infrastructure. It finds the problem first, and you can discover why it happened second.

While dynamic analysis offers many advantages, it has shortcomings as well. Just as its advantages originate from the testing being performed from the outside on a running application, so do its challenges. Some of these challenges are:

  • Requirement for deployed applications: You cannot begin testing until there is a deployed application with an HTTP interface that can be invoked for testing.
  • Potentially incomplete application code coverage: Only the parts of the application discovered during the Explore phase are known to the scanner and tested: the user needs to verify that the necessary parts are explored. For example, some application paths may only be executed if certain inputs are passed as parameters to the application, but it is very unlikely that a dynamic analyzer can exhaustively test an application with all of the possible inputs.
  • Limited information available via HTTP: Testing from the outside means that the analysis does not know what happened inside. Vulnerabilities may remain hidden from the scanner, while still being detectable by an attacker through careful analysis of the application’s logic.
  • Impossible to point to the problem source: Dynamic analysis identifies problem locations in terms of URLs and parameters, but does not have visibility into the lines of code or server components from which the problem originated.

Static analysis

Static analysis tools look at the source code and binaries of an application, figure out how the application works, and build mathematical models of that behavior. The tools then query the models to check whether the application’s behavior exposes security weaknesses. In contrast to the dynamic analysis approach, in static analysis nothing actually gets executed: the whole analysis is based purely on mathematical models.

Static analysis is often referred to as White-Box scanning, implying that it is the opposite of Black-Box. In Black-Box, the application is a sealed single entity. In White-Box, all of the internals of the application (the code) are out in the open, exposed to the analyzer.

There are different types of models and analyses within static analysis. Some look at the access permissions to methods and classes, some analyze configuration and runtime permissions of a process. Each looks at different models and does different queries. For Web applications, the most important type of security static analysis is called taint flow analysis. This analysis aims at identifying the flow and use of untrusted data within an application.

When performing taint flow analysis, the scanner models the flow of data within the system. If data from an untrusted input source (for example, a form field) makes its way to a sensitive output sink (for example, a database call) without the application’s ensuring that that input is not malicious, a security issue is reported. The untrusted data is referred to as tainted data, while the code ensuring that the data is not malicious is called a sanitizer, and is often said to clean the taint.

The strength of static analysis lies in the high visibility it has into the code, and the fact that the mathematical models it builds can account for all possible execution flows through the given code. By looking at the actual code of the application, static analysis can identify all of the ways that data can enter or exit the application, and can track the flow and actions performed on it along the way.

The benefits of static analysis, therefore, include:

  • Detection of more types of issues: Since it is not limited to issues that can be tested through the external HTTP interfaces, static analysis can test for trust levels, bad security practices, and a variety of other issues not visible to dynamic analysis.
  • Broad range of target programs: Having visibility into other data entry points (such as files being read and environment variables being checked), static analysis can verify absence of problems in virtually any program, not just Web applications. Some of these properties can be tested dynamically, too, but are not part of the currently available dynamic analysis tools.
  • Clear code coverage: Because the code itself is being scanned statically, achieving code coverage is as simple as specifying what code should be included in the analysis scope.
  • Reduced sensitivity to client-side technology: Seeing the entry points to the application in the code eliminates the need that dynamic analysis tools have to "drive" the application through its clients, making scanning rich Internet applications (RIAs) for server-side issues as easy as scanning traditional Web applications.
  • No need for a user interface (UI): You can start identifying flaws before a UI or a full working flow is available.

The challenges in static analysis come from the fact that it has no visibility into modules and code that it does not see or understand. For example, if a program is constructed of different components (some of which have no source code, or are written in languages that the static analyzer does not support), the analyzer may not be able to model the execution of all of those components.

Because it models the way that the application behaves, static analysis has to have full visibility and understanding of how that application code works, or it will not be able to determine whether a particular vulnerability exists.

This very limitation also means that static analysis may not be able to determine if external systems (such as a firewall) protect an application against a particular vulnerability, or whether a hacker indeed has access to specific information flows. This means that static analysis cannot determine if:

  • A vulnerable page is ever deployed
  • A Web application’s file system cannot be accessed by anyone but the administrator
  • A specific public function in the code is never actually called
  • And so on

While defensive programming principles state that these issues should be resolved, static analysis is very limited in its ability to help the user identify the higher exposure and higher risk issues necessary for prioritizing the user’s work items.

To summarize, the weaknesses of static analysis include:

  • Limited to code it can see: Code that a static analyzer does not see may include closed-source third party components (such as COTS software), operating systems, databases, and Web Infrastructure components. It is often hard to even get the code of components developed by other internal teams within the same organization.
  • Limited to code it can understand: For example, static analysis tools need to build dedicated support for each language and every development platform used. They are also constantly challenged by programs that determine data flow at runtime.
  • Cannot determine exploitability and mitigating factors: Often, a static analyzer cannot automatically assess the exploitability of certain issues, or the presence of mitigating factors. This results in a large number of issues that are hard to prioritize properly, and in an increased number of false positives.
  • Does not test for integration issues: The security of a system requires that all of the system components be secure when integrated with each other. Issues may result from different handling of input by the different application components or the underlying infrastructure. This results in vulnerabilities that would be difficult to discover if the components were analyzed as isolated modules. These issues only surface when you test the application in its fully deployed state.

String analysis

Another downside of static analysis technology today is the need to carefully configure sanitizers.

The sanitizer configuration problem

The fact that data from a form parameter made its way to a database through an SQL query only becomes a problem if that data was not properly sanitized on the way.

While existing tools do a good job of identifying the application’s inputs (sources) and outputs (sinks), they do not automatically identify if sanitization was done. The configuration needs to specify which functions are the sanitizer functions that clean the data.

Since most Web applications rely heavily on data being passed between the users and the database, not having the sanitizers properly configured results in an overwhelming number of issues, the vast majority of which are false positives. The user then needs to sift through those, manually flagging all of the sanitization functions, to get to a point where only the real issues are shown.

This activity is tedious, time consuming, and error-prone, requiring careful inspection of each sanitization function in all possible contexts. It often requires an understanding of both the specific application’s code and the security activities. This usually implies that it requires a developer and security expert working together, doubling the required investment.

Another variation of this problem is the use of validators. In some cases, data is not sanitized, but instead simply checked as to whether it is valid or not. If the data is not clean, an error is returned, and processing stops.

This technique is a valid way to keep the system secure, but because there is no real sanitization of the data (only conditions on it), current static analysis tools do not properly analyze such code. The only solution is to refactor (in other words, modify) the code to perform the sanitization, enabling a tool to understand it.

The solution: string analysis

Rational AppScan Developer Edition introduces in its static analysis engine an exciting innovation called string analysis. String analysis, as its names implies, applies deeper processing of strings seen while building the models of the code. This allows the subsequent queries to ask much more accurate questions (and to obtain much more accurate answers) when determining the existence of vulnerabilities.

The foundation of string analysis involves tracking all of the possible values that a string may contain while it traverses through the code. As a string enters the application, it is likely seen as an open string, possibly holding any character. If all quotes are now removed from that string by some function in the application code, the string analysis model detects that this string cannot possibly hold quotes from here on.

Next, when it identifies a tainted piece of data included in an SQL query, the static analysis engine will be able to determine whether hazardous characters may still be present (implying that a security problem exists). The string analysis model strings are grammars, enabling a very detailed understanding of the characters and sequences that a string might hold at any point in the execution flow.

In the example shown in Listing 1, the input string variable is tracked. String analysis automatically computes that by the time it is concatenated to the SQL command, it cannot include single quotes or semicolons.

Listing 1. Tracking the input string variable
public void submitQuery(String userName) 
{
    userName = clean(userName);
    String query = "SELECT id FROM users WHERE name = '" + userName + "'";
    execute(query);
}
public String clean(String input) 
{
    return input.replaceAll(";","").replaceAll("'","");
}

Note: At public String, input is ".*" and at return, input is "[~;']*"

This use of string analysis takes the ease-of-use and accuracy of static analysis to the next level. It removes the need to configure sanitizers, supports validators, and eliminates the code-refactoring requirement. It also is not sensitive to user mistakes, where a function may be wrongfully marked as a sanitizer, or a sanitizer may miss a character or sequence of characters.

String analysis makes static analysis a valid tool for developers by eliminating the heavy investment and level of security expertise required for sanitizer configuration. The out-of-the-box accuracy, and its having no code-refactoring requirements, make it a viable tool for scanning existing applications (which often present very current risks).

The real potential of string analysis

Rational AppScan Developer Edition's primary use of the powerful string analysis is to eliminate the need for sanitizer configuration. However, that is actually just the first manifestation of the potential of string analysis. Another use of string analysis, currently under development in IBM, is to allow static analysis to follow data outside the code boundaries (by performing contextual analysis on strings that leave the domain of the application code).

Consider a page on a forum application where a user defines her public name, as shown in Listing 2.

Listing 2. Define a public name
statement.executeUpdate("UPDATE Users SET PubName='" +  SqlEncode(Name) +
     "' WHERE UserName = '" + SqlEncode(UserName) + "';");

When the user posts a message, another page pulls the name and displays it next to each message posted by the user, as shown in Listing 3.

Listing 3. Display the public name
ResultsSet rs = statement.executeQuery("SELECT PubName FROM Users " +
     " WHERE UserName='" +  SqlEncode(UserName) + "';");

Assuming that this username is now written directly to the HttpResponse, that means that a Persistent Cross-Site Scripting (XSS) vulnerability exists: tainted data made its way to the HttpResponse without being sanitized against XSS.

Traditional static analysis cannot handle this scenario, because the data leaves the scope of the code when it gets written to the database. Static analysis tools are typically left with a tough choice. They can possibly miss many issues, or they can mark any writing of data into the database (or reading and presenting of data from the database) as a security issue. More often than not, they default to the latter, resulting in a huge amount of false positives, which make the tools virtually unusable.

Using string analysis, the analyzer can parse and understand the SQL statements being passed to the database. This allows it to verify that the information in this specific table and column may be tainted, but not reduce the trust level for other data read from this database. Similar logic can be applied to:

  • Reading and writing to and from specific files
  • Making calls into authentication servers
  • Many other protocols

Even that is not the only use of string analysis. Its potential guarantees that it will be the foundation for a new generation of static analysis technology.


Runtime analysis

Earlier, this article explained how dynamic analysis is performed on a running application, but has no visibility into internal activity. It has also covered how static analysis has full visibility into the application, but runs on static information, not seeing how the analyzed code behaves in real time, or how it interacts with its surrounding.

Runtime analysis works in between the two. It monitors the internal activities in the application while it is being invoked, giving more visibility to dynamic analysis and adding runtime validation to static analysis.

The common flow of Runtime Analysis usage includes the following steps:

  • Using static analysis to learn about the application actions that should be monitored
  • Injecting hooks into the compiled application (or the running environment) to monitor those activities
  • Gathering information from those hooks while performing dynamic analysis
  • Refining the dynamic analysis results and next steps

The type of information that runtime analysis gathers varies greatly. Examples include:

  • Monitoring what code got executed to measure code coverage
  • Monitoring I/O activity to identify test payloads that made it all the way through the application code
  • Monitoring memory allocations to uncover leaks and other potential paths leading to running out of memory

While runtime analysis is a very powerful addition to other analysis techniques, it is important to clarify that it does not work alone: it can only strengthen another activity.

Execution flow

One challenge with the use of dynamic analysis in development is that issues are reported on a URL and a parameter. While those are sometimes sufficient for a developer to point to the code involved, it often is not enough, and developers need to spend precious time finding the location of the bug.

To overcome this problem, Rational AppScan Developer Edition uses runtime analysis to identify the exact code executed when invoking each dynamic analysis issue. This execution flow, presented in a textual or graphical fashion, points a developer directly to the line of code involved. This makes it easier to find the source of the problem and resolve it.

Code coverage

Another common concern for users of dynamic analysis tools is knowing if they invoked the majority of actions in the applications. When you set such a tool to explore an application automatically, it is all too easy to miss out on large sections of the application. Dynamic analysis tools today make it easy to add a missed section to a scan, but it is often hard to determine if parts were indeed missed (and if so, which ones).

Runtime analysis reveals the automated explore as well. By monitoring the code executed during this automated explore, it is easy to understand the percentages and specific areas invoked during the scan quickly.

Given that knowledge, it is simple to tune the configuration and ensure a more successful scan. Rational AppScan Build Edition leverages powerful capabilities from the Eclipse Test and Performance Tools Platform (TPTP) and IBM® Rational® Application Developer frameworks to visualize and quickly understand the exact coverage achieved in the scan.

It is worth noting that coverage is less of an issue when a user manually steps through the application to discover areas for the dynamic analysis engine to analyze. This simpler approach is usually better when you are aiming at a smaller scope, such as those usually performed by developers before checking in their code for a specific task.


Composite analysis

The article has discussed the three main analysis techniques, including both their value and potential issues regarding using them in isolation. Rational AppScan Developer Edition blends these various techniques to leverage their strengths and to compensate for their weaknesses. How is this achieved?

As shown previously, dynamic, static and runtime analyses each have their pros and cons.

By using the techniques side-by-side, you can benefit from the strengths of all of them. This enables you to find issues in the third party components, along with issues from a malicious file input source and more. A security-aware organization clearly reduces its risk by using both techniques.

However, Rational AppScan Developer Edition does not stop there. By using the two techniques together, you can alsoleverage each technology to overcome the weaknesses of the other. You can use dynamic analysis to determine exploitability and help prioritize static analysis results, while static analysis can automatically configure dynamic analysis, greatly reducing the configuration required to achieve proper coverage.

Results correlation

The most immediate embodiment of composite analysis is correlating the sets of issues found by the static and dynamic analyses. Correlating the results produces a high priority set of issues that are discovered using both approaches.

Each issue in this group is proven to be exploitable by dynamic analysis. The exact flow of its tainted data through the code is provided by static analysis. In this way, its accuracy is practically guaranteed, because it was found in two very different ways. These issues should clearly be at the top of the priority list.

Combining the two sets of issues is not simple: dynamic analysis speaks in terms of URLs and parameters, while static analysis discusses classes and lines of code. Fortunately, the execution flow provided by runtime analysis helps Rational AppScan Developer Edition map the dynamic analysis issues to the code involved, where they can be matched up against the code involved in a static analysis issue.

This is critical for accurate correlation, because the reverse correlation (mapping static analysis issues to the URL and parameter level) requires accurate information and understanding of the application deployment, not often available to a static analysis tool.

Symbiotic analysis

Results correlation is just one example of composite analysis. The real strength lies in helping one analysis technique guide the other. For example, static analysis can be used to determine all of the Web entry points to an application, and feed that information to a dynamic analysis tool. This helps it achieve a high level of coverage automatically.

On the flip side, dynamic analysis can inform a static analysis on which inputs are visible to an outside user, helping the latter prioritize its issues and identify back-doors (or maintenance hooks) left hidden in the code.

Rational AppScan Developer Edition is the first product to tap into the enormous potential of combining the different analysis techniques. Because this is an exciting new path, you can be sure to see more exciting innovations and capabilities added in each release.


Helping each other out

The previous sections have described a variety of strengths that each analysis technique provides. However when analysis techniques are used together, their combined strength can help overcome, or at least greatly mitigate, the weakness of individual methods. Table 2 shows how static and runtime analysis together help overcome the challenges in dynamic analysis.

Table 2. Solutions to the limitations of dynamic analysis
ProblemSolution
Requires a deployed applicationStatic analysis supports analyzing applications before their interface is available.
Application/code coverage not guaranteedRuntime analysis easily measures exact code coverage of the scanned application.
Limited to info available via HTTPStatic and runtime analyses provide detailed visibility into the application's behavior, before and during the scan.
Can't point to problem sourceDetailed code execution flow is gathered for every dynamic analysis issue, thanks to the runtime analysis engine.

In turn, Table 3 shows how the static analysis engine is strengthened by the new string analysis capability and the support of dynamic analysis techniques.

Table 3. Solutions to the limitations of static analysis
ProblemSolution
Limited to code it can seeString analysis expands the visibility of static analysis into the database, file system, and others. Dynamic analysis tests the application in real time, implicitly taking into account all contributing factors.
Limited to code it can understand and does not test for integration issuesDynamic analysis uncovers issues without requiring deep understanding of their cause, providing the user with rich information to assist in determining the components at fault.
Cannot determine exploitability and mitigating factorsResults correlation with dynamic analysis helps flag the exploitable issues that are in most immediate need of attention, separating them from the issues whose remediation is an important but secondary step.
Requires extensive up-front investment to achieve accurate resultsString analysis offers out-of-the-box accuracy, eliminating the need for sanitizer configuration and code refactoring.

What you have learned

To summarize, Rational AppScan Developer Edition is designed to be the best Web application security solution for developers. It is an easy to use security solution that is built into the development environment and process, producing highly accurate and easy-to-understand results.

Rational AppScan Developer Edition is the first to offer all of the dominant security analysis technologies in one product, and is the first to tap into the potential of using these techniques together. This results in a comprehensive security assessment of your applications, efficient and accurate scanning, and clear prioritization of tasks in the large endeavor of securing your organization's Web applications.

The strengths offered by Rational AppScan Developer Edition are the sum of the strengths of the different technologies embedded in it, as well as those offered by the combination of them. The end result is a product that:

  • Finds the broadest set of issues, whether they originate in code, integration, third-party components, or other parts.
  • Provides highly accurate, extremely informative, and clearly prioritized results, making remediation as efficient and simple as possible
  • Is extremely easy to use, using available technologies to offer automation and more information wherever needed.
  • Can scan applications in practically any state, whether they have a deployed user interface, whether only code or only a deployed instance is available, and so on.
  • Can overcome challenging server and client side technology, using the right technology at the right place.

In addition, Rational AppScan Developer Edition exemplifies IBM's deep understanding of developers, build environments, and the software delivery process. The combination of different technologies provides an extremely powerful engine, and that engine is harnessed specifically to meet a developer's needs.

Rational AppScan Developer Edition is a great addition to the AppScan family of Web application security solutions, and it opens the door for handling Web application security in development: the right step towards meeting this challenge.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational, Security
ArticleID=337067
ArticleTitle=Developing secure Web applications: An introduction to IBM Rational AppScan Developer Edition
publish-date=09162008