Guidelines for Application Security Management-Design,

Development & Testing

ITS-GL020, Ver 1.1

Sharda Centre, Off Karve Road, Erandwane,

Pune, Maharashtra, India 411004

www.techmahindra.com

Copyright © 2013, Tech Mahindra. All rights reserved.

Company-Confidential GUIDELINES FOR APPLICATION SECURITY MANAGEMENT
– DESIGN, DEVELOPMENT AND TESTING

Table of Contents

1. PURPOSE..................................................................................................................................... 3
2. SCOPE.......................................................................................................................................... 3
3. ACRONYMS AND DEFINITIONS ................................................................................................. 3
4. GUIDELINE - INSTRUCTIONS .................................................................................................... 3
4.1 DESIGN...................................................................................................................................... 3
4.2 CODING ..................................................................................................................................... 4
4.3 SECURITY TESTING ................................................................................................................... 4
4.4 DELIVERY AND DEPLOYMENT ...................................................................................................... 4
4.5 TYPES OF VULNERABILITIES ........................................................................................................ 5
4.6 MANAGEMENT PRACTICES .......................................................................................................... 7
4.6.1 Requirements, Design and Development ...................................................................... 7
4.6.2 Testing ........................................................................................................................... 7
4.7 AUDIENCE .................................................................................................................................. 7
4.8 VERIFICATION MATRIX ................................................................................................................ 7
4.9 TESTING TOOLS ......................................................................................................................... 9
4.9.1 Introduction .................................................................................................................... 9
4.9.2 Evaluation Criteria ....................................................................................................... 10
4.9.3 Common Tools and Features ...................................................................................... 12
5. DOCUMENT HISTORY .............................................................................................................. 16

ITS-GL020I1.1 Business Management System Page 2of 16

Company-Confidential GUIDELINES FOR APPLICATION SECURITY MANAGEMENT
– DESIGN, DEVELOPMENT AND TESTING

1. PURPOSE
The purpose of this Application Security Management is to define the requirements for security in all
applications that use the Web Application Security Standards (WASS. Security rules safeguard
applications, and the underlying information, by preventing unauthorized alteration, destruction or loss
of use

2. SCOPE
The intended audience for this Management Practice is all users with responsibility for the
development, implementation and management of security in applications.

This document presents only rules required for application security; all other methodologies for
development remain the same as per QMS/BMS. Any other type of security like Network etc. must be
considered separately.

3. ACRONYMS AND DEFINITIONS

Term/ acronym Explanation

BMS Business Management System

4. GUIDELINE - INSTRUCTIONS
The logical activities for software development life cycle for a Web Application development project
phases given below:

4.1 DESIGN
The applicable rules to be considered while design secure web applications are

Authentication Rules 1,2,3

Authorization Rules 4,5
Session Management Rules 8,10
Input Validation Rules 13,14,15,17
Error Handling Rules 18,19,20
Information Security Rules 23,25
Cryptography Rules 30,31,32
Environment and Application Server Rules N/A
Logging Rules 36
Entry Approval of SRS
Baselines SRS
Security Requirements
Inputs
Classification of Information stored in
Application under design
Ensure Compliance to Applicable rules
Tasks
Refer: WASS document for details
Verification / Validation Design Review
Updated Traceability Matrix
Outputs Review Reports
Design Document

ITS-GL020I1.1 Business Management System Page 3of 16

Company-Confidential GUIDELINES FOR APPLICATION SECURITY MANAGEMENT
– DESIGN, DEVELOPMENT AND TESTING

Exit Reviewed detailed modeling elements

4.2 CODING

All rules in WASS document are applicable during the coding phase depending on the type of
application (Level1, Level 2, Level 3) however for Unit Testing and Code Review, verification Matrix in
this document can be referred.

Entry Approval of Design Document

Base lined Design Document
Inputs Security Requirements
Classification of Information stored in Application under design
Code according to the coding standards and method specifications
Tasks
Checklist for Code Review
Verification / Unit Testing
Validation Code Review
Base lined source code
Code Review Reports
Outputs
Updated Traceability Matrix
Review Reports
Exit Base lined source code

4.3 SECURITY TESTING

All rules in WASS document are applicable during the Security testing phase depending on the type of
application (Level1, Level 2, Level 3) however verification Matrix in this document can be referred for
any details.

Entry Completion of one round of Functional testing

Functionally Stable Application
Inputs Security Requirements
Classification of Information stored in Application under design
Tasks Perform Automated and Manual Security testing
Verification /
Reviewed and Approved Security Test Reports
Validation
Tested ( for security ) source code
Outputs Security Test reports against WASS
Review reports
Exit Base lined and Tested application

4.4 DELIVERY AND DEPLOYMENT

Authentication Rules 1
Authorization Rules NA
Session Management Rules NA
Input Validation Rules NA

ITS-GL020I1.1 Business Management System Page 4of 16

Company-Confidential GUIDELINES FOR APPLICATION SECURITY MANAGEMENT
– DESIGN, DEVELOPMENT AND TESTING

Error Handling Rules 19

Information Security Rules 27,29
Cryptography Rules NA
Environment and Application Server Rules 33,34,35
Logging Rules 36

Entry UAT sign-off by the customer

Tested deliverables
Acceptance criteria as defined in project plan
Contract for information on deliverables agreed with the
Inputs customer
Project Plan for any specific replication, delivery and onsite
installation
requirements
Develop Deployment plan
Document delivery checklist
Tasks
Conduct pre-delivery checks
Deliver the work products
Verification /
Deployment plan
Validation
Deployment plan
Outputs Product Delivery Checklist
Review Reports
Sign off from customer on delivered and accepted
Exit
application.

4.5 TYPES OF VULNERABILITIES

Some of the top issues associated with web applications that must be addressed are shown in the
following diagram

ITS-GL020I1.1 Business Management System Page 5of 16

Company-Confidential GUIDELINES FOR APPLICATION SECURITY MANAGEMENT
– DESIGN, DEVELOPMENT AND TESTING

A bad design can cause potential problems for different types of security vulnerabilities. The following
table lists the vulnerabilities, category wise and the potential problems that can be caused due to bad
design.

Rule Category Vulnerability Type Rule ID

Insufficient Authentication 1
Authentication Rules Weak Password & Password
2,3
Recovery Validation
Insufficient Authorization 4,7
Parameter Manipulation 5,6
Authorization Rules
Insecure Direct Object Reference 4,6
Cookie Poisoning 4,5,6,7
Session Hijacking 8,9,10
Session Management Rules Session Fixation 9
Insufficient Session Expiry 11
SQL Injection (Injection Flaws) 13,15,16
Input Validation Rules Cross Site Scripting (XSS) 14,16
Malicious File Execution 17
Error Handling Rules Improper Error handling 18,19,20
21,22, 23,24, 25,26,
Information Security Rules Information Leakage
27,28,29
Cryptography Rules Insufficient Cryptographic Storage 30,31,32

Directory Indexing 33
Environment and
Application Server Rules Transport Layer Security 35
Database Security 34
Logging Rules Auditing & Logging 36

ITS-GL020I1.1 Business Management System Page 6of 16

Company-Confidential GUIDELINES FOR APPLICATION SECURITY MANAGEMENT
– DESIGN, DEVELOPMENT AND TESTING

4.6 MANAGEMENT PRACTICES

4.6.1 Requirements, Design and Development

 Before an Application is developed, acquired or enhanced, security requirements must be
formally documented to address all relevant security rules as defined in Web Application
Security Standards
 Each Project must establish mechanisms to certify the completeness of security requirements
of each High Risk Application within formally documented project review processes.
 Application design specifications must be formally documented to address all security
requirements.
 Applications should rely on approved IT Services (e.g., Strategic Enterprise Directory, Single
Sign On, Microsoft NTLM, etc.) for security processes (e.g., authentication, authorization).
 A formal plan (either separate plan or integrated with the project plan) must be documented for
Level 1 Applications and approved by the business owner.

4.6.2 Testing
 New or Significantly Enhanced version releases of Applications (including Legacy Applications)
must be fully tested against applicable security rules prior to production deployment.
 Confidential Information should not be used for purposes of application development and
testing. The use of Confidential Information for development and testing must be authorized by
the business owner of the Application.
 Successful testing of an Application’s security rules must be recorded in accordance with formal
change control processes.
 Personally Identifiable Information (PII) must not be used in application development or testing,
unless otherwise permitted under applicable data protection laws, rules or regulations (e.g.,
Healthcare Information Portability and Accountability, EU Data Protection Directive).
 Where the use of Confidential Information is required for test purposes, access controls must be
applied to Applications and underlying systems in the test environment. Confidential Information
must be deleted from the test environment as soon as feasible following test execution.

4.7 AUDIENCE

 The standards must be shared with the customer, customized (if required) and approved before
putting it to use. This must happen before the application design starts.
 Project Teams are accountable for ensuring that web applications within their scope are
compliance with this standard.
 Project Architects are accountable for ensuring that this standard is appropriately complied with
on projects where they are the named architect.
 Project Managers should ensure that compliance with this standard is included in System
Requirements.
 Developers are responsible for developing code that complies with this standard.
 Web Security Testers must ensure that the application is not vulnerable to vulnerabilities
described in this document.

4.8 VERIFICATION MATRIX

Compliance to WASS can be verified in several ways. This section documents a recommended
method of verifying each Rule.
Each Rule maybe verified in two ways. Manual Testing is a series of security related tests available
that may be used to verify most Rules. Rules which cannot be verified by Manual Testing will require
Code Review. Code Review requires access to the source code of the application.

ITS-GL020I1.1 Business Management System Page 7of 16

Company-Confidential GUIDELINES FOR APPLICATION SECURITY MANAGEMENT
– DESIGN, DEVELOPMENT AND TESTING

The Verification Matrix is provided as an aid to navigate the various Rule statements. A indicates that
the Rule statement is verifiable via the corresponding verification technique. Multiple check marks
means the Rule statement is verified by a combination of techniques.

Verification
Rule Responsibility
Rule Description
ID Code Manual
Review Testing
1 Do not allow the login process to start from an unencrypted page.
Password strength should be enforced to use upper and lower case
2
letters, numbers, and symbols.
Password aging should be enforced to ensure that passwords do
3
not remain unchanged for long periods of time.
4 Validate authorization on every request.
Employ Access control in the business layer, not only the
5
presentation layer.
Do not pass any credentials or parameters that can be used to
6
bypass authentication or authorization rules within a URL.
Ensure that all URLs and business functions are protected by an
7 effective access control mechanism that verifies the user’s role and
entitlements.
Only use the inbuilt session management mechanism within the
8
development framework
Ensure that a new session is regenerated upon successful
9
authentication.
10 Ensure that every page has a logout link.
Use an appropriate timeout period that automatically logs out an
11
inactive session.
Do not accept new, preset or invalid session identifiers from the
12
URL or in the request.
Use a standard input validation mechanism to validate all input data
13 for length, type, syntax, and business rules before accepting the
data to be displayed or stored
Ensure that all user-supplied data is HTML/URL encoded before
14
rendering.
15 Use strongly typed parameterized queries or stored procedures.
Validate any application critical information passed as variables in
16
cookies.
Check any user supplied files or filenames taken from the user for
17
legitimate purposes.
18 Avoid detailed error messages that are useful to an attacker.
Utilize custom error pages in order to guarantee that the application
19
will never leak error messages to an attacker
In the case of any system failure, the application must "fail closed"
20
the resource
21 Do not store any confidential information in cookies.
22 Prevent Sensitive Data from Being Cached on Client Side.
Ensure that confidential information is transmitted by using HTTP
23
POST Method.
24 Do not write / store any sensitive information in HTML source.
Ensure proper masking techniques are used while displaying
25
Sensitive Personally Identifiable Information to users.

ITS-GL020I1.1 Business Management System Page 8of 16

Company-Confidential GUIDELINES FOR APPLICATION SECURITY MANAGEMENT
– DESIGN, DEVELOPMENT AND TESTING

26 Do not use hidden fields for sensitive data.

Avoid exposing private object references to users whenever
27
possible, such as primary keys or filenames.
Do not save passwords within cookies to allow users to be
28
remembered.
Do not store any confidential information including passwords in log
29
entries unless encrypted.
Do not use weak cryptographic algorithms or create cryptographic
30 algorithms for the generation of random numbers used in security-
related processes.
Employ one-way hash routines (SHA-1) to encrypt passwords in
31
storage.
Use Cryptographically secure algorithms to generate the unique
32 IDs being used in the URL's, hence securing the URLs from being
re written.
Ensure that Infrastructure Credentials such as database credentials
33
or message queue access details are properly secured.
Employ the Principle of Least Privilege while assigning rights to
34
execute queries.
35 Encrypt confidential information in transit across public networks.
Provide an appropriate logging mechanism to detect unauthorized
36
access attempts.

4.9 TESTING TOOLS

4.9.1 Introduction
Three types of tools are predominantly used to analyze web security issues:

Source Code Analyzers:

The primary users of these types of tools are developers who analyze the source code for patterns
that often lead to vulnerable software. Modern security analyzers are more sophisticated; they use
data- and control-flow analysis to find subtler bugs and to reduce false alarms. They focus on building
security in software source code, trying to automate some of the tasks that a human analyst might
perform. Unfortunately, these tools are still not capable of replacing a human analyst. Currently,
security analyzers do not unambiguously and flawlessly detect vulnerabilities, and it is therefore
erroneous to refer to such a tool as a vulnerability detector. While there is some vulnerability that can
be detected with high accuracy, others are harder to detect, and, in fact, one can always devise
vulnerabilities that are undetectable altogether. Security analyzers are used to make human analysts
more efficient; they automate certain mechanical tasks and even certain tasks that are easier for
machines than for humans.

Vulnerability Scanners:
Taking the concept of network-based vulnerability scanner one step further, application scanners
began appearing several years ago. These tools attempt to do probing of general purpose web-based
applications by attempting a variety of common and known attacks on each targeted application and
page of each application. Most application scanners can observe the normative functional behavior of
an application and then attempt a sequence of common attacks against the application. The attacks
include buffer overruns, cookie manipulation, SQL insertion, cross-site scripting (also referred to as
“XSS”), and the like. Although this feature set sounds as though it might be of significant value to a
test team that is evaluating a web-based application, the chief shortcoming of the technology is that
the tools only test for a relatively small and simplistic set of attack profiles—for example, putting a few
hundred “A” characters into a string variable to look for a buffer overrun situation. Further, since the
testing is still performed in an entirely black box manner, the utility of such tools is greatly diminished
to any serious testing process. That is, although failing any of the tests is demonstrably a bad
situation, passing all of the tests can only provide, at best, a misplaced sense of security. Popular
commercial application scanners include IBM’s Appscan and HP WebInspect.

ITS-GL020I1.1 Business Management System Page 9of 16

Company-Confidential GUIDELINES FOR APPLICATION SECURITY MANAGEMENT
– DESIGN, DEVELOPMENT AND TESTING

Web Application Assessment Proxy:

Although they only work on web applications, web application assessment proxies are perhaps the
most useful of the vulnerability assessment tools listed here. Assessment proxies work by interposing
themselves between the tester’s web browser and the target web server. Further, they allow the tester
to view and manipulate any and all data content flowing between the two. This gives the tester a great
deal of flexibility in trying different “tricks” to exercise application weaknesses in the application’s user
interface and associated components. This level of flexibility is why assessment proxies are
considered essential tools for all black box testing of web applications. For example, the tester can
view all cookies, hidden HTML fields, and other data in use by a web application and attempt to
manipulate their values to trick the application into allowing access where the tester should not be
able to get to. Changing cookie values such as “customerID” can have startling results on poorly
developed applications. Popular web application proxy tools include Paros Proxy and OWASP’s
WebScarab, available from http://www.parosproxy.org/ and http://www.owasp.org/, respectively.

4.9.2 Evaluation Criteria

The following is a list of evaluation criteria that may be considered when selecting a security testing
tool. Not all of the criteria listed below may be relevant to all test all test projects.

Ease of Use

 Intuitive and easy to use for users new to automated testing tools
 Easy to install; tool may not be used if difficult to install
 Tasks can be accomplished quickly, assuming basic user proficiency
 Easy to maintain automated tests, with a central repository that enables users to separate GUI
object definitions from the script
 Can vary how designs and documents are viewed (zooming, multipage diagrams easily
supported, multiple concurrent views); basic windowing

Tool Customization

 Fully customizable toolbars to reflect any commonly used tool capabilities

 Tool customizable: fields added, deleted
 Fully customized editor with formats and colors for better readability
 Tool support for required test procedure naming convention

Breadth of Testing

 Can be used with non-Microsoft platforms (UNIX, Linux, FreeBSD, Mac)

 Tests for common website vulnerabilities
 Evaluates the test environment as well as the software
 Supports standard web protocols for fuzzing and domain testing.

Test Coverage and Completeness

Coverage refers to the ability of the tools to test for all (known) categories of vulnerabilities relevant to
the product that has been developed. It is important to obtain a sense of the percentage and nature of
potential vulnerabilities the tools tests for. For example, if evaluating a web-based system, the
organization will want to determine whether the test tool identifies issues that may result from
improper input validation, SQL insertion attacks, cross-site scripting attacks, or improper session
management.

Accuracy/False-Positive Rate

 Are there a large number of false positives? False positives will result in more analysis work for
the tester, who will be required to manually evaluate the results of the test tool.
 Are there a large number of unidentified vulnerabilities?

ITS-GL020I1.1 Business Management System Page 10of 16

Company-Confidential GUIDELINES FOR APPLICATION SECURITY MANAGEMENT
– DESIGN, DEVELOPMENT AND TESTING

Test Language Features

 Allows add-ins and extensions compatible with third-party controls

 Does not involve additional cost for add-ins and extensions
 Has a test editor/debugger feature
 Test scripting language flexible yet robust; allows for modular script development
 Scripting language not too complex
 Scripting language allows for variable declaration and use and for parameter to be passed
between functions
 A test script compiler or an interpreter used?
 Allows for interfacing and testing of external .dll and .exe files
 Published APIs: Language Interface Capabilities
 Tool is not intrusive: source code of application does not need to be expanded by inserting
additional statements or dlls for the application to be compatible with the tool
 Allows for data-driven testing
 Allows for automatic data generation
 Allows for adding timers for timing transaction start and end
 Allows for adding comments during recording
 Allows for automatic or specified synchronization between client and server
 Allows for object data extraction and verification
 Allows for database verification
 Allows for text (alphanumeric) verification
 Allows for wrappers (shells) whereby multiple procedures can be linked and called from one
procedure
 Allows for automatic data retrieval from any data source—RDBMS, legacy system,
spreadsheet—for data-driven testing
 Allows for use of common spreadsheet for data-driven testing
 Ease of maintaining scripts when application changes

Test Management

 Supports test execution management

 Support for industry standards in testing processes (e.g., SEI/CMM, ATLM, ISO)
 Interoperability with tools being used to automate traditional testing
 Application requirements management support integrated with the test management tool
 Requirements management capability supports the trace of requirements to test plans to
provide requirement coverage metrics
 Test plans can be imported automatically into test management repository from standard text
files
 Can be customized to organization’s test process
 Supports planning, managing, and analyzing testing efforts; can reference test plans, matrices,
product specifications, in order to create traceability
 Supports manual testing
 Supports the migration from manual to automated scripts
 Can track the traceability of tests to test requirements
 Has built-in test requirements modules
 Can check for duplicate defects before logging newly found defects
 Allows for measuring test progress
 Allows for various reporting activities
 Allows for tracking of manual and automated test cases
 Has interface to software architecture/modeling tool
 Is integrated with unit testing tools
 Has interface to test management tool
 Has interface to requirements management tool
 Has interface to defect tracking tool
 Has interface to configuration management tool
 Provides summary-level reporting
 Includes error filtering and review features

ITS-GL020I1.1 Business Management System Page 11of 16

 Company-Confidential GUIDELINES FOR APPLICATION SECURITY MANAGEMENT
– DESIGN, DEVELOPMENT AND TESTING

 Enables metric collection and metric analysis visualization

Interoperability

Major test automation suites provide functionality that is useful in any large-scale testing process. For
smaller, more specialized tools,interoperability with other test tool suites may be considered as an
evaluation criterion.

Consulting Requirements

 Maturity of vendor
 Market share of vendor

Vendor Qualifications

 Financial stability of vendor

 Length of time in business
 Technological maturity

Vendor Support

 Software patches provided, if deemed necessary

 Upgrades provided on a regular basis
 Upgrades backward compatible: scripts from previous version can be reused with later
version
 Training available
 Help feature available; tool well documented
 Tech support reputation throughout industry
 No consulting needed?
 Availability of and access to tool user groups

Product Pricing

 Price consistent within estimated price range

 Price consistent with comparable vendor products
 ROI compared to current in-house technology
 ROI compared to in-house development of needed technology

4.9.3 Common Tools and Features

Listed below are certain tools that are commonly used in security testing projects. However it is
recommended that proper evaluation needs to be done before selecting a tool. In an ideal scenario a
combination of tools are used to determine the strength of security in web applications.

Tool Type Tool Name Vendor Features Website

FxCop is an application
that analyzes managed
code assemblies (code that
targets the .NET
Framework common
Source
language runtime) and http://msdn.microsoft.com/en-
Code FxCop Microsoft
reports information about us/library/bb429476(VS.80).aspx
Analyzer
the assemblies, such as
possible design,
localization, performance,
and security improvements.
Many of the issues concern

ITS-GL020I1.1 Business Management System Page 12of 16

 Company-Confidential GUIDELINES FOR APPLICATION SECURITY MANAGEMENT
– DESIGN, DEVELOPMENT AND TESTING

violations of the
programming and design
rules set forth in the Design
Guidelines, which are the
Microsoft guidelines for
writing robust and easily
maintainable code by using
the .NET Framework.
The Fortify Source Code
Analyzer (SCA) examines
every line of code and
every program path to
Source
identify hundreds of
Code Fortify Fortify http://www.fortify.com
different types of potentially
Analyzer
exploitable vulnerabilities
early in the development
lifecycle, when they're
cheapest to fix.
HP DevInspect software is
web application security
assessment software
designed to thoroughly
Source analyze today's complex
https://h10078.www1.hp.com/cda/hpms/display/main/
Code DevInspect HP web applications. It delivers
hpms_content.jsp?zn=bto&cp=1-11-201-200_4000_100__
Analyzer fast scanning capabilities,
broad assessment
coverage and accurate
web application scanning
results.
DevPartner Studio
Professional is a suite of
tools allowing a developer
to analyze .NET code for
Code Quality and
Complexity Memory Leak
Detection Memory
Optimization Performance
Source Analysis (Timing)
Code Compuware Performance Expert (CPU, http://www.compuware.com/quality.htm
Analyzer Disk and Network resource
usage) Code Coverage
Analysis Fault Simulation
(both .NET and
environmental) Error
Detection and Interop
monitoring for C/C++ using
BoundsChecker
technology.
Rational AppScan provides
Vulnerability Web application security
AppScan IBM http://www.ibm.com/software/rational/offerings/websecurity/
Scanner vulnerability scanning,
testing, and reporting.
HP WebInspect software is
Vulnerability web application security https://h10078.www1.hp.com/cda/hpms/display/main
WebInspect HP
Scanner assessment software /hpms_content.jsp?zn=bto&cp=1-11-201-200_4000_100__
designed to thoroughly

ITS-GL020I1.1 Business Management System Page 13of 16

 Company-Confidential GUIDELINES FOR APPLICATION SECURITY MANAGEMENT
– DESIGN, DEVELOPMENT AND TESTING

analyze today's complex

web applications. It delivers
fast scanning capabilities,
broad assessment
coverage and accurate
web application scanning
results.
Acunetix WVS
automatically scans your
web applications & web
services for vulnerabilities
to SQL injection, Cross site
Vulnerability
Acunetix Acunetix scripting, Google hacking & http://www.acunetix.com/
Scanner
other web attacks. WVS
can analyze websites using
SOAP & AJAX and
includes PCI Compliance
reporting
Burp Suite is an integrated
platform for attacking web
applications. It contains the
entire Burp tools with
numerous interfaces
between them designed to
facilitate and speed up the
process of attacking an
application. All tools share
the same robust framework
for handling HTTP
requests, persistence,
authentication, upstream
Vulnerability proxies, logging, alerting
Burp Suite Portswigger http://portswigger.net/suite/.
Scanner and extensibility. Burp
Suite allows you to
combine manual and
automated techniques to
enumerate, analyze, scan,
attack and exploit web
applications. The various
Burp tools work together
effectively to share
information and allow
findings identified within
one tool to form the basis
of an attack using another
http://portswigger.net/suite/.
WebScarab is a framework
for analyzing applications
that communicate using the
HTTP and HTTPS
Web WebScarab&
OWASP protocols. It is written in
Application Other http://www.owasp.org/index.php/Category:
(Open Java, and is thus portable
Assessment OWASP OWASP_WebScarab_Project
Source) to many platforms.
Proxy Tools
WebScarab has several
modes of operation,
implemented by a number
of plugins. In its most

ITS-GL020I1.1 Business Management System Page 14of 16

 Company-Confidential GUIDELINES FOR APPLICATION SECURITY MANAGEMENT
– DESIGN, DEVELOPMENT AND TESTING

common usage,
WebScarab operates as an
intercepting proxy, allowing
the operator to review and
modify requests created by
the browser before they are
sent to the server, and to
review and modify
responses returned from
the server before they are
received by the browser.
WebScarab is able to
intercept both HTTP and
HTTPS communication.
The operator can also
review the conversations
(requests and responses)
that have passed through
WebScarab
Web
Application Used for web application
Paros Free http://www.parosproxy.org/
Assessment security assessment
Proxy
Fiddler is a Web
Debugging Proxy which
logs all HTTP(S) traffic
between your computer
and the Internet. Fiddler
allows you to inspect all
HTTP(S) traffic, set
breakpoints, and "fiddle"
Web with incoming or outgoing
Application data. Fiddler includes a
Fiddler Free http://www.fiddler2.com/fiddler2/
Assessment powerful event-based
Proxy scripting subsystem, and
can be extended using any
.NET language. Fiddler is
freeware and can debug
traffic from virtually any
application, including
Internet Explorer, Mozilla
Firefox, Opera, and
thousands more.
TamperIE is a simple
Internet Explorer Browser
Web
Helper Object which allows
Application
TamperIE Free lightweight tampering of http://www.bayden.com/TamperIE/
Assessment
HTTP requests from
Proxy
Internet Explorer 5 and
above.
Web
TamperData is an
Application
Tamper Data Free extension to track and https://addons.mozilla.org/firefox/addon/966
Assessment
modify http/https requests
Proxy

ITS-GL020I1.1 Business Management System Page 15of 16

Company-Confidential GUIDELINES FOR APPLICATION SECURITY MANAGEMENT
– DESIGN, DEVELOPMENT AND TESTING

5. DOCUMENT HISTORY

Version Date Author Reviewed Approved by Nature of changes

(function) by
Issue 19-April- VijayaGanguly, Ankita Ravi Chippa, TechM-MSAT
1.0 2013 Kumar Choudhury NamdevMahadik integration issue
Niranjan
Issue 02-Aug- Raghuram G Senthilkumar Thenmozhi S Ported template in
1.1 2013 S new integrated
template format post
merger.

ITS-GL020I1.1 Business Management System Page 16of 16