May 2016 edition
Notices
IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative
for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not
intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or
service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate
and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this
document does not grant you any license to these patents. You can send license inquiries, in writing, to:
IBM Director of Licensing
IBM Corporation
North Castle Drive, MD-NC119
Armonk, NY 10504-1785
United States of America
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY
KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some jurisdictions do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein;
these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s)
and/or the program(s) described in this publication at any time without notice.
Any references in this information to non-IBM websites are provided for convenience only and do not in any manner serve as an
endorsement of those websites. The materials at those websites are not part of the materials for this IBM product and use of those
websites is at your own risk.
IBM may use or distribute any of the information you provide in any way it believes appropriate without incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other
publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other
claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those
products.
This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible,
the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to
actual people or business enterprises is entirely coincidental.
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corp., registered in many
jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM
trademarks is available on the web at “Copyright and trademark information” at www.ibm.com/legal/copytrade.shtml.
© Copyright International Business Machines Corporation 2016.
This document may not be reproduced in whole or in part without the prior written permission of IBM.
US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
V11.0
Contents
TOC
Contents
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Course description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Unit 1. Introduction to software development & application security. . . . . . . . . . . . . . . . . . . . . . 1-1
Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Introduction to software development & application security (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Introduction to software development & application security (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
Basics of programming languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
Compiled versus interpreted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9
Program utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
Programming concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12
Distributed programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
Threats and malware (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15
Threats and malware (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-18
Importance of software development life cycle (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20
Importance of software development life cycle (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22
Software development methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24
Adherence to secure software development principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-27
Web application security principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-28
Application design & development security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-30
Environment and controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-31
Essence of secure software development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-32
Auditing and assurance mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-34
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-36
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-37
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-38
Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-39
Unit 2. Introduction to input validation & sensitive data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Introduction to input validation & sensitive data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Implementation of input validation (1 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
Implementation of input validation (2 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
Implementation of input validation (3 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
Practical solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
Input validation vulnerability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
Buffer overflow (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13
Buffer overflow (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
Cross-site scripting (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
Cross-site scripting (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
SQL injection (1 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19
SQL injection (2 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21
SQL injection (3 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-22
Canonicalization (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-24
Canonicalization (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-26
Sensitive data (1 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-27
Sensitive data (2 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-29
Sensitive data (3 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-31
Sensitive data access (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-33
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
iii
V11.0
Contents
TOC
Sensitive data access (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-35
Sensitive data in storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-37
Information disclosure (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-39
Information disclosure (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-41
Data tampering (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-43
Data tampering (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-44
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-45
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-46
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-47
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-48
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-49
Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-50
Unit 3. Introduction to authentication & authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Introduction to authentication & authorization (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Introduction to authentication & authorization (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5
Network eavesdropping (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
Network eavesdropping (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
Brute force attack (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11
Brute force attack (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
Dictionary attack (1 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15
Dictionary attack (2 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-16
Dictionary attack (3 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18
Cookie replay attack (1 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19
Cookie replay attack (2 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21
Cookie replay attack (3 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23
Credential theft (1 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-25
Credential theft (2 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-26
Credential theft (3 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-28
Elevation of privilege . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-29
Basics of authorisation (1 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-30
Basics of authorisation (2 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-31
Basics of authorisation (3 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-33
Data tampering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-34
Luring attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-35
Phishing attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-36
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-37
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-38
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-39
Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-40
Unit 4. Introduction to configuration management & session management . . . . . . . . . . . . . . . . 4-1
Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Introduction to configuration management & session management (1 of 2) . . . . . . . . . . . . . . . . . . . . 4-3
Introduction to configuration management & session management (2 of 2) . . . . . . . . . . . . . . . . . . . . 4-4
Unauthorized access to administration interfaces (1 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
Unauthorized access to administration interfaces (2 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
Unauthorized access to administration interfaces (3 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10
Unauthorized access to configuration stores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
Retrieval of clear text configuration data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
Lack of individual accountability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15
Over-privileged process and service accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16
Basics of Session Management (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17
Basics of Session Management (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19
Hijacking attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
iv
V11.0
Contents
TOC
Session replay attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-22
Man in the middle attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-25
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-27
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28
Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-29
Unit 5. Introduction to cryptography, parameter manipulation & exception management. . . . . 5-1
Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Introduction (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
Introduction (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
Poor Key Generation or Key Management(1 of 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
Poor Key Generation or Key Management (2 of 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9
Poor Key Generation or Key Management (3 of 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11
Poor Key Generation or Key Management (4 of 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12
Weak or Custom Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14
Basics of Parameter Manipulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16
Cookie Manipulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18
HTTP Header Manipulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-19
Basics of Exception Management (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-20
Basics of Exception Management (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-22
Denial of Service (1 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-23
Denial of Service (2 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-25
Denial of Service (3 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-27
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-29
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-30
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-31
Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-32
Unit 6. Auditing & Logging, Countermeasures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
Introduction to Auditing & Logging, Countermeasures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
Basic Countermeasures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6
Basic Countermeasures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8
Basic Countermeasures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-12
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-13
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-14
Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-15
Unit 7. Lab Exercise Introduction to Code Analysis using IBM Rational AppScan . . . . . . . . . . . 7-1
Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
Installation (1 of 8) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
Installation (2 of 8) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4
Installation (3 of 8) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5
Installation (4 of 8) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6
Installation (5 of 8) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-7
Installation (6 of 8) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8
Installation (7 of 8) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9
Installation (8 of 8) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10
AppScan run procedure (Web Services Explorer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11
AppScan run procedure (Web Services Explorer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12
AppScan run procedure (Web Services Explorer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13
AppScan run procedure (Web Services Explorer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-14
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
v
V11.0
Contents
TOC
AppScan run procedure (Web Services Explorer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-15
AppScan run procedure (Web Services Explorer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-16
AppScan run procedure (Web Services Explorer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-17
Source code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-18
Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-19
Appendix A. Review answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
vi
V11.0
Trademarks
TMK
Trademarks
The reader should recognize that the following terms, which appear in the content of this training
document, are official trademarks of IBM or other companies:
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business
Machines Corp., registered in many jurisdictions worldwide.
The following are trademarks of International Business Machines Corporation, registered in many
jurisdictions worldwide:
DB™
Notes®
z/OS®
DB2®
Parallel Sysplex®
Initiate®
System z®
Microsoft, Windows and Windows NT are trademarks of Microsoft Corporation in the United States,
other countries, or both.
Java™ and all Java-based trademarks and logos are trademarks or registered trademarks of
Oracle and/or its affiliates.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Other product and service names might be trademarks of IBM or other companies.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
vii
V11.0
Course description
pref
Course description
IT Application Security
Purpose
This course will help you to learn information technology application security. The whole gamut of information
technology application security in this book spans across seven units. In the first unit you will be introduced
with software development and application security. The second unit will deal with input validation and
sensitive data handling. The third unit focuses on authentication and authorization. The fourth unit will walk
you through configuration management and session management. The fifth unit is about cryptography,
parameter manipulation, and exception management. The sixth unit will make you aware of auditing and
logging, and its countermeasures. The final unit is a lab that will familiarise you with IBM rational AppScan.
Important
This course consists of several independent modules. The modules, including the lab exercises, stand on
their own and do not depend on any other content.
Audience
Add your audience profile here ...
Prerequisites
This course is designed keeping in view of the engineering students with basic knowledge of the subject.
Objectives
In this course you will learn to understand
• To understand software development methodology and application security
• To design input validation strategies and protect sensitive data
• To develop effective authentication and authorization strategies
• To secure an application’s configuration management features and user sessions
• To implement cryptography, prevent parameter manipulation, and manage exceptions
• To list audit and logging considerations and take countermeasures
• To conduct application scan using IBM rational AppScan
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
viii
V11.0
Unit 1. Introduction to software development & application security
Uempty
Unit 1. Introduction to software
development & application
security
Overview
This unit provides an insight on programming languages, software development life cycle, secure application
development principles, and secure software development.
How you will check your progress
• Checkpoint
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-1
V11.0
Unit 1. Introduction to software development & application security
Uempty
Unit objectives
IBM ICE (Innovation Centre for Education)
IBM Power Systems
After completing this unit, you should be able to:
•
•
•
•
•
Get an overview of traditional and modern programming languages
Understand the software development life cycle and its components
Gain insight on the need of application security
Identify the secure application development principles
Comprehend secure software development methodology
© Copyright IBM Corporation 2016
Figure 1-1. Unit objectives
Notes:
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-2
V11.0
Unit 1. Introduction to software development & application security
Uempty
Introduction to software development &
application security (1 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Software development requires the understanding of the following:
– Basics of software development
– Essence of software development
– Knowhow of software development
© Copyright IBM Corporation 2016
Figure 1-2. Introduction to software development & application security (1 of 2)
Notes:
Basics of software development
The compound word software development has two parts, software plus development. Here the first part,
software is a well-defined collection of computer programs. And, a computer program is a well-defined
collection of computer codes written in a programming language. A computer program is built using the
concept of stacking and nesting of computer codes and the execution of the codes is governed by the
programming logic of sequence, selection, and repetition. The role of a computer program is basically to
perform the desired task as coded by a computer programmer, who is otherwise known as a software
developer. A computer program thus enables a computer to take input, process it, and generate result(s) as
output. A computer software, thereby, governs computer hardware and brings it to functionality. Without
software a computer cannot perform data processing, number crunching, and web application tasks that
need the usage of Internet, servers, and electricity. On the other hand, the second part development is the
process of creating, improving, and advancing a computer program in a logical manner adhering to the latest
and improved algorithms and data structures that consolidate a computer program. An optimized computer
program minimizes time and space complexity, which needs innovation, research, and endeavour from the
software developer’s end. The art of computer programming is a wonderful, imaginative, and revered job that
is ever appreciated by humankind. Once a logical set up of the optimized computer programs are made and
is consolidated as a software, it can be used for application or operating system purpose as it is intended.
Therefore, the task of a software developer is to develop software for computer system that can act as an
operating system or can be tailor-made for a specific application such as web application, database
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-3
V11.0
Unit 1. Introduction to software development & application security
Uempty
application, or custom application. Therewith, software development is a process of creating a new software
or improving the existing software that caters to the current needs of computing devices, organizations,
groups, or individuals by planning, designing, implementing, testing, and maintaining the developed software.
Essence of software development
The contemporary world has seen a paradigm shift from paper-based work environment to computer-based
work environment. The need to provide and obtain information in the quickest possible manner gave impetus
to information technology. Now you can see a world completely and universally reliant on the computing
power of computers, group of interconnected computers, and the worldwide group of interconnected
computers therefrom constituting a network such as intranet, extranet, and the Internet. Software
development is essential to provide an organisation the power to render information as an embodiment of
omnipresence, omniscience, and omnipotence to users. This you can understand from the following
scenario. You are now in this present-day digital world and you need to know certain information related with
your queries. You can of course bing it or google it to get what you desired. Indeed, your search now has just
transmigrated from the traditional library-based search to get hold of the requisite books to obtain information
to electronic-based search using the latest search engine that provides the same and better search quality in
a jiffy. So, what is this search engine. To your surprise search engines are nothing more than a software that
performs a thorough search from the humongous databases scattered world-wide to cater to what you need
in your search result. These search engines such as Bing, Yahoo, or Google basically does the task of
searching content on the basis of your keywords that you have typed on the search text box. This might give
you a perspective that when you need to know about an organisation, product, or anything you desire you
can by all means take the help of these search engines and obtain the result as information. This is why all
organizations and product and customer driven companies want their product and services to be visible in the
first page of the search result, thereby bringing more clients and business to the organization. Now to make
the searches visible the following things need to be done: first make a web application promoting your
company, its essence, and services; second market your web application to make it search engine
optimizable so that it can rank at the top of the search list; last but not the least make your web application
secure.
Knowhow of software development
Software development needs an in-depth understanding of programming languages, involves a systematic
approach for its development process, obligates the use of software development life cycle, and expedites
the development procedure by pursuing a standard and befitting software development methodology. The
choice of language depends upon the usage and requirements of the user, business, or computational
machine. The programming languages as invented from the antiquity of computer generation to modernity
are machine language, assembly language, high level language, very high level language, and natural
language. Being a modern being you must follow the latest technology, nouveau software development
methodology, and the future-ready programming language. This will not only help you to develop
state-of-the-art application software but also implement robust application security that will protect
information from misuse, breaches, and tampering, thereby making information safe, secure, and stable.
Now, after you have decided the language that you will use to develop the software, you are also willing to
take a systematic approach to develop the software, are ready to experience the software development
process through various phases as portrayed in the software development life cycle, and are willing to
execute the cutting-edge software development methodology; then you should make a proposal document
for the organization to which you are developing the software. Begin your journey of software development
from the feasibility analysis by ensuring financial soundness and technical feasibleness of the proposed
software development project. Then proceed to the requirement analysis and specification so that you can
understand the clienteles’ requirements and organize it in a working document. There is no mathematical or
logical approach to requirements gathering, nevertheless you can follow the footsteps of experts through
interviewing, questionnaires, observations, review of policies and records of the organization, and creating
crisp data flow diagrams or flowcharts to analyse the requirements of the business. From the analysis, you as
an analyst can conclude whether the timeframe of creating the software matches the programming-hours
needed to complete the software within agreed deadline. You can strengthen human-capita that are involved
in the programming and make the project successful.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-4
V11.0
Unit 1. Introduction to software development & application security
Uempty
Introduction to software development &
application security (2 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Application security requires the understanding of the following:
– Fundamentals of application security
– Nitty-gritties of application security
– How-tos of application security
© Copyright IBM Corporation 2016
Figure 1-3. Introduction to software development & application security (2 of 2)
Notes:
Fundamentals of application security
Application security refers to the controls or countermeasures that are included within and applied to system
and application software, which include operating system and specific software developed for particular
purpose such as web application, database application, etc. Specialized security controls are required in
database applications to manage security risks inherent in volume of data being handled, and for web
applications due to accessibility requirements that create risk of infiltration of information system. During the
software development life cycle, you must develop software in a secure and controlled manner so that the
developed software should have controls built to support the security goals of the organization. The security
risks that crop up in the software development discipline include malware, bugs, unseen vulnerabilities, and
careless programming practices, which form the major means for attackers to achieve unauthorized access,
system intrusions, breaches of security and integrity, network misuse, and other offensives. In addition,
improper processing impacts integrity that maintains the accuracy of data, development errors often create
problems for availability that eases users to access data correctly, and protecting information for improper
disclosure and protecting the secrecy and privacy of sensitive data that ensure confidentiality. During the
security system testing, you must perform application security testing to evaluate the controls over the
application and process flow, which include the application’s resistance to buffer overflow, usage of
encryption to protect the confidentiality and integrity of application, user authentication, integrity of the
Internet user’s session with the host application, and use of cookies. You must address application security
vulnerability category in an organized way by adhering to secure architecture and design guidelines. The
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-5
V11.0
Unit 1. Introduction to software development & application security
Uempty
vulnerability focus for secure software development include input validation (IV), sensitive data (SD),
authentication, authorization, configuration management (CM), session management (SM), cryptography,
parameter manipulation (PM), exception management (EM), auditing and logging, which are the key areas
where errors are most often committed.
Nitty-gritties of application security
Application plays a vital role in imposing the security of the system through appropriate controls, edit checks,
and audit trails. Applications can incur challenges for software developers, graphic designers, and system
architects if they want to create a robust application keeping security perspective in mind. In order to create
the most secure and hack-resilient applications, you need to build the application meeting all the current
security needs. If the application is not securely designed, then there will be concerns for its deployment as it
can lead to security breaches. When organizations offer access to core business functionality through
web-based applications, new security vulnerabilities are introduced. Even with a firewall and other monitoring
systems, security can be endangered when data traffic must be permitted to pass via firewall. Then you need
to implement the concepts of application security to safeguard against security breaches. As an information
security professional, you must understand the application development environment in order to provide input
and guidance for including security controls into application development projects. Application should be
developed in a secure and controlled manner, and have controls built to support the security goals of the
organization. Some software such as malware have been deliberately developed to break the security of
information systems, and this area requires particular study as well. Note that malware is not the only security
risk in the software arena. Bugs, unseen vulnerabilities, and careless programming practices are the major
means for attackers to achieve unauthorized access, system intrusions, breaches of security and integrity,
network misuse, and other offensives. In addition, improper processing destroys integrity and development
errors often create problems for availability. Software can be either a security weakness or a security
strength. Properly designed and implemented software can help enforce the accuracy of changes to data,
ensure that data is not shared with unauthorized people, ensure that the systems function correctly through
balancing and reports, and track all access to data.
How-tos of application security
You need to apply sound design and architectural best practices, incorporate organization’s security policies
and standards, and reflect on deployment strategies in order to build a robust application. Database
applications, while a mature and established technology, have specialized requirements and security risks
inherent in the volume of data being manage. Web applications also have specific risks, due to the
accessibility requirements, which can have some of the major points of attack for penetration of information
system as a whole, owing to the fact that web servers are often connected on both sides of a firewall.
Remember from computer and security architecture perspective, application versus operating system is a
highly simplified view of the complexity of an actual computer operation, and also that complexity is the
enemy of security. Note that software protection controls may be applied to any or all of the components, and
that software development controls should be applied to all. Also note that, with the complexity of the many
components that can be involved in a given application, management and controls on the development of the
system are all the more important. Systems and Software Development Projects rarely meet the expectations
of the business and seldom integrate the required security principles into the final product. It is important that
an organization follows good project management controls, which include a systems development
methodology like Systems Development Life Cycle (SDLC) that include the involvement of the business and
the security department throughout the lifespan of the project. This includes change management controls
over the project to prevent uncontrolled changes to the project and the dangers of developing ‘scope creep.’
The complexity of business processes and systems today makes security more difficult than ever. Many
applications are built to interface with numerous backend systems or data sources – often through some form
of Middleware. The integration of data and systems makes the protection of data all the more difficult to
ensure compliance with privacy regulations.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-6
V11.0
Unit 1. Introduction to software development & application security
Uempty
Basics of programming languages
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Generations of programming languages are as shown below:
– First generation
• Machine language
– Second generation
• Assembly language
– Third generation
• High-level language
– Fourth generation
• Very high-level language
– Fifth generation
• Natural language
© Copyright IBM Corporation 2016
Figure 1-4. Basics of programming languages
Notes:
Basics of programming languages
Programming languages were developed over the years and improved in both ease of use and increased
functionality. This has made programming of an application much simpler but has also increased the risk due
to ‘non-professional’ programmers developing applications without security controls or following proper
programming practices. All organizations have to ensure that they have proper backups of all software, as
well as documentation of the function of the software.
Generations of programming languages
Now, let’s discuss about traditional & modern programming languages that are categorized in five
generations as follows:
First generation: Machine language is the first generation programming language that uses binary codes in
the form of bits comprising of series of 0s & 1s, vacuum tubes as internal circuits for processing of codes,
magnetic drums for storing coded data, and was prevalent in the year 1940 to 1956. Humans are not good at
remembering numbers and hence this language was difficult for programmers to memorize the code,
understand the programming, and utilize the language with ease.
Second generation: Assembly language is the second generation programming language that uses
mnemonic codes comprising of small words representing commands such as ADD, MUL, etc., transistors for
internal circuits for processing of codes, magnetic tapes for storing of coded data, and was prevalent in the
year 1956 to 1963. Mnemonics though helpful to the programmer for coding and understanding but was not
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-7
V11.0
Unit 1. Introduction to software development & application security
Uempty
easy for general users. Assembler extracts machine language code that computer understands from the
assembly language program, thereby helping the computer to execute the code.
Third generation: High-level language is the third generation programming language that uses human
understandable traditional code for creating programs such as while, if, etc.; integrated circuits for processing
of programs; magnetic disk for storing coded data; and was prevalent in the year 1964 to 1971. The
programming language has introduced the concept of control structures, data structures, machine
independence of program using complier that can convert the program to machine dependent code for
execution, etc. Examples of high level language include C, Pascal, ADA, Algol, etc.
Fourth generation: Very high-level language is the fourth generation programming language that uses
declarative, object oriented, and English-like programming language commands independent of the
traditional input, process, and output logic; micro-processors for processing of programs; and was prevalent
in the year 1971 to present. The programming language focuses on what part rather than how part to perform
the task. Examples of very high-level language includes SQL, Visual Basic, Lisp, etc.
Fifth generation: Natural language is the fifth generation programming language that currently uses artificial
intelligence technology and is presently used in various computing devices including mobile phones; some of
the famous current AI implementation includes Cortana from Microsoft, Google Now from Google, and Siri
from Apple. The technology is in nascent stage and will continue to prevail for some time in the future. The
programming language utilizes particular algorithm to solve pertinent problems.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-8
V11.0
Unit 1. Introduction to software development & application security
Uempty
Compiled versus interpreted
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• The programming languages are categorized as follows:
– Compiled language
– Interpreted language
– HTML, XML, and Active X
© Copyright IBM Corporation 2016
Figure 1-5. Compiled versus interpreted
Notes:
Compiled versus interpreted
Now you are aware of the various generations of programming language, let’s discuss about other
categorization of programming languages. Note that the choice of a programming language can have
implications for security. The programming languages are also categorized as Complied Language,
Interpreted Language, and HTML, XML, & Active X Language as discussed in the following topics:
Compiled languages
A more human readable language that is the source code is translated to more optimized machine language,
which is the machine code. It may be argued that almost any language can be compiled.
• COBOL, Fortran: Common Business Oriented Language and Formula Translation are some of the
original high-level programming languages. The “goto” construct in Fortran is derided for contributing to
unstructured “spaghetti” code.
• BASIC: Beginners All-purpose Symbolic Instruction Code as its name implies was designed for the
non-technical person to be able to write programs.
• Pascal: Modest, reliable, and effective programming language designed to teach systematic
programming concepts, named after the mathematician Blaise Pascal. The Pascal language enabled the
programmer to define their own datatypes.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-9
V11.0
Unit 1. Introduction to software development & application security
Uempty
• C: Devised in 1972 by Dennis Ritchie as a system implementation language for the operating system
named UNIX. The use of strcpy in C leads to a tendency of buffer overflow conditions.
• Ada: Originally designed for embedded and real-time systems, which require a high degree of
dependability. When compiled, if there are ambiguities the compiler for Ada will most likely reject the
code.
• C++: Is an enhancement to “C with Classes” adding the following: exception handling, templates, multiple
inheritance, operator overloading, and virtual functions.
• Java: Java is a programming language designed, developed, and distributed by Sun Microsystems. The
machine language is extracted from the Java program via compilation. Java compiler converts source
code into bytecode, which is the machine code for a Java Virtual Machine.
• C#: Takes an opposite view of programming focusing architecture first and the syntax second. Most
compiled languages are written without consideration of the underlying architecture. C# focuses on the
underlying Common Language Infrastructure (CLI) specification. C# can be used on multiple computer
platforms.
• Visual Basic: The goal of a visual programming language is to ease programmer in programming though
visual or graphical means incorporating the concepts of object oriented programming (OOP) language.
Interpreted languages
• REXX: Restructured extended executor is a scripting language designed to be easy to read and lean.
• PostScript: Is a page description language for desktop publishing and laser printers developed by
Adobe. It solved the crude dot matrix versus plotter printing problem.
• Perl: A scripting language originally developed for text manipulation. Its major strength is the
programmer supported community Comprehensive Perl Archive Network (CPAN). CPAN is the largest
freely available code library.
• Ruby: Where most scripting languages are optimized for speed on the computer, ruby is optimized for
user experience.
• Python: According to the author of Python Guido van Rossum, “Python is an interpreted, interactive,
object-oriented programming language. It incorporates modules, exceptions, dynamic typing, very high
level dynamic data types, and classes. Python combines libraries, as well as to various window systems,
and is extensible in C or C++. It is also usable as an extension language for applications that need a
programmable interface. Finally, Python is portable: it runs on many Unix variants, on the Mac, and on
PCs under MS-DOS, Windows, Windows NT, and OS/2.”
HTML, XML, and Active X
While these entities are related to programming, and some will refer to programming with them, they are not
programming languages as such.
• HTML: HTML is a language, but its use is for page layout and display.
• XML: XML defines the nature or characteristics of the data and what each piece of data means or
represents. It is actually used in conjunction with other languages, such as HTML. A number of XML
derived languages have security implications for web applications.
• Active X: Active X is an underlying architecture that form the basis for high level software facilities
including transmitting, sharing, and retrieving data among various applications. The technology
Component Object Model (COM) is used in Active X controls and has found niche in one of the operating
system of Microsoft: Windows CE. It is not really a programming language. Another Microsoft technology
sometimes identified with programming is Object Linking and Embedding (OLE), which is a data format.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-10
V11.0
Unit 1. Introduction to software development & application security
Uempty
Program utilities
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Program utilities include:
–
–
–
–
Assembler
Compiler
Interpreter
Hybrid
© Copyright IBM Corporation 2016
Figure 1-6. Program utilities
Notes:
Program utilities
• Assembler: Translates assembly language to machine language. There is a close correspondence
between assembly mnemonic codes and machine opcodes.
• Compiler: Translates a high-level (source) language into machine language.
• Interpreter: Instead of compiling a program at once, the interpreter translates it statement-by-statement.
• Hybrid of compilation and interpretation. There is also hybrid of compilation and interpretation.
Source code is compiled into an intermediate stage, similar to object, machine, or assembly code. In
Java, this is known as bytecode. The intermediate stage code is then interpreted as needed. The intent of
the two-step process is to provide for compatibility between systems, since machine code is platform
specific. The interpreter, the Java Virtual Machine in Java, is particular to each platform, but can handle
the intermediate code produced on any platform. Java is not the only language to use this type of system.
It was implemented as long ago as the UCSD-p system for Pascal.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-11
V11.0
Unit 1. Introduction to software development & application security
Uempty
Programming concepts
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Programming requires the knowledge of the following concepts:
– System model
– Von Neumann architecture
– Object Oriented Programming (OOP)
© Copyright IBM Corporation 2016
Figure 1-7. Programming concepts
Notes:
Programming concepts
In modern, large-scale applications, the system model may be extremely complex. The specifics of the
source code, tools and configuration are vital in distinguishing the version or build of the program. A common
testing failure is improper specification of the system model to be tested, resulting in tests being performed on
the wrong program.
System model: Instructions regarding source code files, development tools (such as compilers), and options
to be used in creating the program or application.
Von Neumann architecture: Is now used so widely that it is sometimes thought to be the only architectural
model. In the Von Neumann architecture, there is no difference between data and code. Code can be
processed as data; data can be executed. Malware can modify existing programs. Malformed input can inject
data into locations where it will be executed as programming.
Other architectures do exist, such as the “Harvard Architecture” used and promoted by Howard Aiken. The
strict distinction between data and instruction under the Harvard architecture would have prevented programs
from modifying other programs and would have prevented input data from being executed as code.
Object-Oriented Programming (OOP): The OOP concept is used in C++, which is the composite of C with
object oriented programming features. The basic merit of OOP is its code reusability that reduces
development time and minimizes coding cost. Now, if you are developing a program in a language that has
the OOP built into it then you can be rest assured that the code that you type in once can be used by you as
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-12
V11.0
Unit 1. Introduction to software development & application security
Uempty
well as other programmers and vice versa, making it runnable on multiple programs. Various aspects of OOP
can assist with security. Data and functions can be hidden from the outside world. However, functions may
also be hidden from developers, so care must be used when relying on security protection in OOP. Objects
are encapsulated, possibly providing some security. Objects have methods (code with interfaces) and
attributes (data) encapsulated together.
Three main items in OOP
• Classes: Templates for objects.
• Objects: Instances of the classes.
• Message: Objects request services by sending messages to other objects.
Three main features of OOP
Inheritance: An object that is called by another object or program derives its data and functionality from the
calling object.
Polymorphism: Different objects may behave differently to the same command in different manners. An
object that is derived from class for which security has been defined may inherit its security characteristics or
functions. However, note that, due to polymorphism, the functions may not be fully secure in the object..
Polyinstantiation: Creating a new version of an object by changing attributes. May be used in support of
security by removing data, or may be a risk due to removal of security features. Polyinstantiation is also the
technique to control or stop the violations of inferences, thereby permitting numerous versions of the same
data to numerous classification levels. This makes data hiding possible as users in lower level of
classification are unaware of the data present in the higher level of classification level.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-13
V11.0
Unit 1. Introduction to software development & application security
Uempty
Distributed programming
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Distributed programming can use any of the following four major protocols:
–
–
–
–
Distributed Component Object Model (DCOM)
Simple Object Access Protocol (SOAP)
Common Object Request Broker Architecture (CORBA)
Enterprise Java Beans (EJB)
© Copyright IBM Corporation 2016
Figure 1-8. Distributed programming
Notes:
Distributed programming: Distributed programming requires abstract communication between hosts.
Distributed computing entails programs located on different cooperating in the same application. Applications
are divided into components; each can operate in a different location/platform. The four major protocols in
use today are: DCOM, SOAP, CORBA, and EJB.
Distributed Component Object Model (DCOM): This protocol is used specifically by Microsoft and is the
default protocol for Windows operating systems. The protocol’s security was once compromised by the
Blaster worm, which used DCOM to spread itself.
Service Oriented Architecture Protocol (SOAP): “SOAP Version 1.2 provide the definition of the
XML-based information which can be used for exchanging structured and typed information between peers in
a decentralized, distributed environment.” SOAP is a replacement of DCOM.
Common Object Request Broker Architecture (CORBA): It is a platform neutral and an open set of
standard. CORBA grants communication between applications irrespective of its storage location. It is based
upon the Object Request Broker (ORB) concept, which creates the client/server relationship between
objects. Client can utilize ORB on the same computer or gain access to a network for searching and
executing a method on a server object. Note that CORBA, and Object Request Brokers in general, are
examples of the reference monitor concept from security architecture, applied to distributed systems.
Enterprise Java Beans (EJB): EJB is a server side Java component that abstracts both the web server and
the database, it serves a web application via a browser. It places the security requirements on the server
side.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-14
V11.0
Unit 1. Introduction to software development & application security
Uempty
Threats and malware (1 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Threats and malware that affect the security of applications include:
–
–
–
–
–
–
–
Buffer overflow
Denial of service
Race condition
Data hiding
Alternate data streams
Non-technical
Malformed input attacks
• SQL injection
• Unicode attack
– Executable content/mobile code
• Web applets
• Dynamic email
– Object reuse
– Garbage collection
– Trap door
© Copyright IBM Corporation 2016
Figure 1-9. Threats and malware (1 of 2)
Notes:
Basics of threats and malware
Now that we have covered the basic concepts of application security, let’s look at the threats to our
applications including malware. Here is a list of some of the things you should understand at the end of this
unit:
• Identify some common programming vulnerabilities.
• The need for development controls to prevent the deployment of software, databases, business
processes, or networks containing vulnerabilities.
• Identify and describe common malware types.
• Choose controls appropriate for different types of malware.
Threats and malware that affect the security of applications include:
• Buffer overflow: Is the weakness of both poor coding practices and programming language (typically C
or C++). The buffer overflow is one the oldest and most common program vulnerabilities having existed
almost since interactive computing began.
▪ Buffers are the memory containers for programs executed by computers.
▪ Programs in execution define the buffers they will use.
▪ The amount of data that is sent by the program to the buffer is unknown until the time of execution.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-15
V11.0
Unit 1. Introduction to software development & application security
Uempty
▪ Overview is the process of putting more than is expected into a container (buffer) which spills into
some other place.
▪ When data overflows one buffer, it flows into another buffer or another program.
▪ The questions are: Where does the data go? What happens to the data that was in the second
buffer?
▪ When an input is more than is expected, the program should reject the data gracefully.
▪ When the program does not reject the data gracefully, a buffer overflow occurs.
▪ Technically, to stop buffer overflows, you must check all bounds on array and pointer references for
all executing code.
▪ Administratively: Bounds checking is an easy task for one programmer on one system, but to know
how many other programs are running is difficult.
▪ When our computing environment is non-adversarial, users and programmers realize the mistake
and perform their own reset.
▪ When our computing environment is adversarial, attackers will look for these flaws and use them as
an opportunity to execute their code, thus taking control of our computing resources.
• Denial of service: The result of another person or process consuming the resources on the system and
thus limiting the resources for the use of others. It is an attack against availability. Denial of service
generally does not involve erasure or destruction of data or resources. A DOS does not nee to be
complex, for example; invalid searches on website can cause a denial of service.
• Race condition: False assumption about the current state of program or a variable in a program that
allows integrity to be reduced. When two or more processes use the same resource, each process can
falsify depending on the state of that resource being constant. But each process can affect the resource.
For example: the glass is full of water and under an opaque box; whoever gets thirsty first drinks; the
other assumes the glass to be full, and reaches for an empty glass. A particular type of race condition for
file access is a Time of Check (TOC) to Time of Use (TOU).
• Data hiding in digital warrens: A local computer has many places for an adversary to hide information
from normal view. On classic definition digital warren is the slack space, which is the unused portion of
the hard disk between the end of the file and the end of the file cluster.
• Alternate data streams: Also called system forks, are additional hidden data associated with a file. Most
end-user applications will not show these files.
• Non-technical threat: These threats such as legal and regulatory and privacy risk are addressed in the
Legal, Regulatory, Compliance and investigation domain.
• Malformed input attacks: Malformed input, more generally known in security literature as malformed
data, involves various means of getting illicit commands or packets through defensive measures. For
example, denial of service packets that would normally be rejected by a firewall can be fragmented to the
point that the firewall no longer recognizes the individual fragments as malicious. Commands (such as
dir) can be sent to a web server in Unicode (%c0%af), which the server will properly interpret and act
upon, but which a content filter may not recognize as commands. An attack using malformed input
frequently involves commands or code that are somehow crafted to appear to be merely data, hence the
name malformed data. The types of attacks are particularly prevalent in web applications. Developers
may use a shortcut in creating web pages by embedding SQL commands into an actual web link, in order
to have commands passed to the supporting application. Attackers can view the source code, find such
embedded commands, and modify them in an attempt to see what effect the modifications have on the
application. SQL and Unicode are by no means the only forms of data that can be used in this way. The
buffer overflow attack can be seen as a special case of malformed data.
▪ SQL injection: A type of attack in which intruder inserts a sequence of Structured Query Language
(SQL) commands into an SQL statement.
▪ Unicode attack: Unicode representations of control information may be passed by a firewall, but
correctly (negatively) interpreted by the server.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-16
V11.0
Unit 1. Introduction to software development & application security
Uempty
• Executable content/mobile code: Code that is downloaded to the user’s machine and executed.
Running programs on a computer may give the program unexpected access to resources on the
machine. The idea of mobile code is termed by various names including executable content, remote
code, mobile code, mobile agents, downloadable code, and active capsules. Execution of remote source
code can be performed in local machines. Agent software is generally differentiated from other forms of
mobile code by additional autonomy of the program, and should, therefore, be subject to additional
controls. Mobile code threats is implemented through the following:
▪ Web applets: Small programs written in Java, scripting languages, or Active X controls. In regard to
the web, note that Java applets are usually subject to a sandbox, whereas JavaScript has no such
protection.
▪ Dynamic email: Active scripts or links included in email messages. Dynamic email is particularly
dangerous. Unless a specific need is demonstrated, it may be best to have policies restricting the
functions available within email and mail user agent (MUA) software.
• Object reuse: An object previously used for another application or information storage may contain
sensitive residual data. Note that objects may be physical (drive storage) or logical (memory or variable
assignments).
• Garbage collection: De-allocation of storage following program execution. Garbage collection may be
both good and bad. Programs written in C must have specific functions for garbage collection and
memory de-allocation. If this not done, the program may run out of memory. Programs written in Java
have efficient garbage collection and more efficient memory use. However, sometimes memory is
re-assigned without being cleared, and, therefore, precautions must be taken to ensure confidential
information is erased immediately after use.
• Trap door: A mechanism embedded in a program that allows the normal security access procedures to
be bypassed. Another term for trap door is maintenance hook. A maintenance hook typically deals with
the O/S, while trap door is used for applications.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-17
V11.0
Unit 1. Introduction to software development & application security
Uempty
Threats and malware (2 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Additional threats and malware that affect the security of applications are:
–
–
–
–
–
–
Incomplete parameter check and enforcement
Covert channels
Inadequate granularity of controls
Social engineering
Multiple parts to information
Malicious software
• Modern malware is network aware
• Compatibility – platform dominance
• Malware functionality
© Copyright IBM Corporation 2016
Figure 1-10. Threats and malware (2 of 2)
Additional threats and malware
• Incomplete parameter check and enforcement: Failure to check inputs to ensure they do not contain:
malformed data, incorrect type or improper length. This is a special case of malformed input.
• Covert channels: Means of surreptitiously transferring information from a high classification
compartment to a low classification. Covert channels are of the following kinds:
▪ Storage Channels: Communicate by modifying a stored object.
▪ Timing Channels: Transmit information by affecting the relative timing of events.
• Inadequate granularity of controls: A common fault in application is that the application was not
designed to differentiate between users of different levels – for example the application may not be
granular enough to stop a low level user from seeing the same data as a high level user.
• Social engineering: This is always a threat that must be addressed with separation of duties and
training.
• Multiple paths to information: Multiple paths to information occurs when objects and applications allow
several paths (methods) to obtain the same result, such as access a program or data through icons,
menus, or shortcut keys. It is important to ensure that all of these roads enforce the same level of
security.
• Malicious software (malware): Is software or program intentionally designed to penetrate a system,
carry out malicious activity, breach organization’s security policies, or harm the system or network.
Programming errors or bugs do not fall in the category of malware. Examples of malicious software
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-18
V11.0
Unit 1. Introduction to software development & application security
Uempty
include computer virus, trojan horse, remote access trojan (RAT), worm, spyware, adware, ransomware,
zombies, distributed denial of service (DDoS) programs, data diddlers, backdoors, pranks, hoax
warnings, and logic bombs.
▪ Modern malware is network aware: Nearly every computer whether personal or mainframe, which
were previously isolated, are now interconnected. New generation malware leverages network
functionality and flaws to spread across networks, whereas old Trojans were subject to a limited
distribution by fooling users on bulletin board systems (BBS), and old generation viruses needed disk
exchange via sneakernet and infection of shareware or possible pirating of software to disseminate.
Modern malware can be distributed through emailing of executable files as attachment, breaching of
web page’s active content, and attacking directly to web server. Attack payloads can try to breach
objects reachable via the world wide web, disseminate reasonable but deceptive data, can spoil
freely available data on websites, and can deny service by depleting resources.
▪ Compatibility – Platform Dominance: Software compatibility was the main concern of the earlier
computing generations as program written on one computer was not compatible with other
computers. Nevertheless, this had one main advantage in terms of security that the malware or virus
written by a malicious developer needs to create the software for all instances of the platform in
which the software can execute, thereby making the attack widespread and successful. Things
changed dramatically in the modern world when compatibility and dominance of platform became
irrelevant. Now, a software can be run on different machines and at different platform making it
completely platform independent. As a consequence, the security has been weakened. Malware
developed on one operating system environment or hardware can execute on other platforms and
hardware very easily.
▪ Malware Functionality: The development of technology has added more functionality to scripting
languages, macros, and other programs that empowered it to either directly access the resources
and hardware or summon processes or utilities possessing such rights to do so. This has led
programmer to take extra precautionary measures to check the payloads or malicious functions in
the created objects, which was once understood as data and thus resistant to malicious
programming.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-19
V11.0
Unit 1. Introduction to software development & application security
Uempty
Importance of software development life cycle
(1 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Software development life cycle (SDLC) comprises of:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Initiation phase
System concept development phase
Planning phase
Requirements analysis phase
Design phase
Development phase
Integration and test phase
Implementation phase
Operations and maintenance phase
Disposition phase
© Copyright IBM Corporation 2016
Figure 1-11. Importance of software development life cycle (1 of 2)
Notes:
Basics of software development life cycle
Many organizations have great development process in place that do not specifically address security. Either
security is assumed or forgotten. Many organizations use their own customized version of software
development methodology. Irrespective of the development method being followed, the software
development life cycle (SDLC) possesses numerous important phases that can be presented separately or
as a unison. Different authors name these phases differently depending on the project size. The important
aspect is not the name or number of steps, but the fact of having a progressive process that assists in
managing development, and detecting problems before they get too big. There are some diagrams that
represent the cycle in development in as little as 3 steps. This is the most expanded development model with
10 steps and is showcased as follows:
1. Initiate: A project initiates when there is a need in business. Once the need is known, a project manager
is assigned to accomplish the task. The manager then creates a concept proposal document to jot down
the business needs. When concept proposal document is approved from the business, the working
concept is developed.
2. Conceptualize: After the project initiation stage is through, the built concept is analysed to answer
whether the project is appropriate and feasible. The scope of the project is streamlined via project
boundary document that needs consent from senior officials. Next the funding for the project is acquired
and then the planning is initiated.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-20
V11.0
Unit 1. Introduction to software development & application security
Uempty
3. Plan: Once the conceptualization phase is over, further advancement is incorporated in the concept
document by detailing how the organisation will operate its business when the approved project is
deployed and by judging how the project will effect employees and privacy of customers. In planning
phase project tools, schedules, activities, and resources are defined so that the project meets the client’s
requirements on-time and within allotted finance. In addition, this phase also incorporates accreditation
activities, security certification, and high level vulnerability assessment by identification of project security
requirement.
4. Analyse Requirement: Once planning phase is by, user requirements in terms of functionality is
determined and software performance, data, security, and maintenance is accurately and precisely
represented. The project requirements are defined to a level of sufficiency that will meet the system
design specification. Analysis of the requirement is performed in a holistic way by relating it to the
business needs as recognized in the initiative phase and making it testable and measurable.
5. Design : After requirement analysis phase is concluded, system’s physical characteristics is designed. In
this phase the establishment of operating system platform, determination of subsystems and their input
and output, and allocation of resources to processes are performed. The identified subsystems form the
basis to create the comprehensive structure of the system. Partitioning of the subsystems into modules
or units and preparation of in-depth logic specification for each module is performed.
6. Develop: After the system specifications are documented in the design phase, it is translated into
executable software, communications, and hardware. The assembling and testing of the hardware is
performed then the unit testing, integrating, and retesting of the software in undertaken.
7. Integration and Test: After the development phase is completed, the various modules of the system
undergo integration and methodical testing. Users perform functional testing as described in functional
requirements document, which is referred for its complete realization. The system undergoes
accreditation activities and security certification stage prior to the deployment of the software in the
production environment.
8. Implement: Once module integration and testing phase is finished, the developed software is installed
on the client’s machines. The implementation phase terminates after the deployed software is up and
running with complete functionality as mentioned in the requirements document.
9. Operate and Maintenance: After the implementation phase operation and maintenance phase arrives,
which is an ongoing process. In this phase, the deployed software is supervised for functioning as
presented in user’s requirement document and alternations required are noted. In-process review is done
in order to make the developed software effective, efficient, and satisfactory. The software re-enters
planning phase when the alternation of the functionality is mandatory.
10. Dispose: Once the software is accepted and operational in the production environment, the software
development cycle is terminated gracefully by preserving all the important data about the software for
future purpose.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-21
V11.0
Unit 1. Introduction to software development & application security
Uempty
Importance of software development life cycle
(2 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Detailed description of SDLC
–
–
–
–
–
–
–
–
–
Project initiation and planning
Functional design definition
Detailed design specifications
Develop and document
Acceptance, testing and transition to production
Decommissioning/disposal
Critical data
Sanitize/destroy media
Software removal
© Copyright IBM Corporation 2016
Figure 1-12. Importance of software development life cycle (2 of 2)
Notes:
Detailed description of SDLC
Project initiation and planning: The most important aspect to note here is that security should be involved
from the very beginning of the project. And, as we will see when dealing with development methods, work
invested at this early stage will avoid problems and delays later in the process.
• Consider common attacks for this kind of application.
• Spanning Tree analysis.
• Determine risks and security requirements.
Functional design definition: Heed the fact that for each item in the development process, there is a
corresponding security consideration. In fact, sometimes we have to take more steps than the developers do.
At this stage we are considering abstract and sometimes formal security models and principles. We may wish
to apply separation of duties (to processes), least privilege, and possibly even need-to-know factors. Some
input to the project may be based on analysis such as:
• Risk analysis.
• Failure modes and effects analysis.
• Solutions and alternative designs.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-22
V11.0
Unit 1. Introduction to software development & application security
Uempty
Detailed design specifications: Consider, at this stage and later, error and exception handling possibilities.
Design testing strategies, objectives, and specific tests to be run against the application. In this phase flaw
hypothesis method is used. It is a system penetration and analysis technique in which analyses of
documentation and specification is performed to hypothesise flaws. Prioritization of the flaws are set on the
basis of the anticipated probability that the flaw is present, on the simplicity of facing the flaw, and on the
degree of compromise or control loss the flaw could put up.
Develop and document: Note the mention of documentation, which is often neglected in development.
Perform code analysis during this phase: Possibly use code review tools.
Acceptance, testing and transition to production: The critical element in this phase is testing the program
before it is brought into full-line production. Perform operational and destructive tests. Certification and
Accreditation are the final steps involved in accepting the system as described in our section in the Security
Architecture domain. Obtained once the application is in operation. Note that one of the security requirements
will be to have assurance (trust in the proper operations of the controls and mitigation of risk), as well as
functional, security mechanisms.
Decommissioning/disposal: Note the recommendations on media sanitizing from the security management
domain and also the inverse positions on data recovery in investigation.
Critical data: Data which is critically important to support business operations, must be protected from
accidental destruction or erasure.
Sanitize/destroy media: Storage media that has contained sensitive data must be adequately protected –
perhaps through overwriting or destruction to prevent the unauthorized recovery of data.
Software removal: When software is to be removed from systems, make safe and certain that the software
is not being used unexpectedly by other applications and to ensure that software is removed from systems
that are being decommissioned or sold off in order to prevent license violations.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-23
V11.0
Unit 1. Introduction to software development & application security
Uempty
Software development methods
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• There are numerous methods basis which software can be developed such as:
–
–
–
–
–
–
–
–
–
–
–
–
–
–
Waterfall
Spiral method
Clean room
Structured programming development
Iterative development
Joint analysis development
Prototyping
Modified Prototyping Model (MPM)
Rapid Application Development (RAD)
Reuse model
Computer Aided Software Engineering (CASE)
Component-based development
Extreme programming
Agile development
© Copyright IBM Corporation 2016
Figure 1-13. Software development methods
Notes:
Software development methods
There are numerous software development methods that have been developed to meet the strict software
development timeframe and unique requirements of clients. The following list provides brief overview of some
of the most essential methods. When applying, mixing or matching any of these methods to a project ask if
enough risk has been addressed to satisfy the stakeholders.
• Waterfall: This software development method is probably the erstwhile model and can be attributed to
the early 1970’s great minds for its creation. Each phase contains a list of milestones that need to be
covered before the next phase initiates.
• Spiral method: This software development method is a bit peculiar from other methods owing to the fact
that in this method each phase undergoes risk assessment. This helps to predict the cost of completion
of the project, and the revision of schedules is executed as per the outcome; thereby, guiding the officials
to decide whether to cancel or continue the project.
• Clean-room: This software development method focuses on preventing defect in contrast to removing
defect and is followed to create high quality software. This lets developer to writes perfect code at the first
version and controls software bugs, thereby following the zero defect approach to software development.
The development time is minimized by following the strategy of incremental development and code
rework avoidance. Most of the time is spent in the design phase rather than testing phase.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-24
V11.0
Unit 1. Introduction to software development & application security
Uempty
• Structured programming development: This software development method focuses on the quality of
the developed product in terms of security, understandability, consistency, and freedom from software
bugs. It mandates discipline, controlled flexibility, and introspection, which is achieved through
modularized programming, reviews and approvals in each phase, and defined processes, thereby
permitting addition of security in a formalized and structured manner.
• Iterative development: This software development method permits changes in the requirements of the
software from the clients during the stages of its development. It provides flexibility to make successive
refinements in coding, designing, and need of the project. From the security perspective, iterative method
provides challenges to software developers in providing adequate security controls as the requirements,
specifications, and designs changes.
• Joint Analysis Development (JAD): This software development method utilizes management process
to assist software developers to work efficiently by communicating with client at vital phases of the
project. Joint analysis development technique brings together group of users, technical specialists,
coders, and designers during software development life cycle, thereby facilitating software development
process.
• Prototyping: This software development method’s objective is to create a prototype or a simplified
version of an application, give it for review to the client, utilize client’s feedback, and create an improved
version incorporating the feedback. The procedure is repeated until the client accepts the product.
Prototyping involve beginning a concept, designing and making use of the starting prototype, improving
until the prototype is in acceptance stage, and finalizing the project and dispatching the final product.
• Modified Prototyping Model (MPM): This software development method permits for the simplest of the
functionality required by system or component to be installed in a short time frame.
• Exploratory model: This software development method focuses on creating a usable system by making
assumption on system workability combined with insights and suggestions on whatever is presently
available to set requirements.
• Rapid Application Development (RAD): This software development method as the name suggests
uses rapid prototyping, rapid software development tools, and strict time frame in each phase to
complete the project. One caveat in this methodology is that owing to the rapid decision making it may
lead to inadequate design works.
• Reuse model: This software development method as the name suggests uses existing components to
build an application.
• Computer Aided Software Engineering (CASE): This software development method uses computers
for analysing, designing, developing, implementing, testing, and maintaining software in a structured and
systematic way. Software developers must undergo training in order to use CASE tool. Computer aided
software engineering is mainly used in complex, large, and multi-environment projects in which multiple
software components and several people are involved to work in a collaborated environment. Sharing of
common view of the various stages of the software development by various participants in the software
development process is possible with the help of this tool. The tool also helps in organizing task, reusing
designs and codes, reducing software development cost, and improving software quality.
• Component-based development: This software development method uses standardized building
blocks called components for assembling an application rather than developing it. This method helps to
develop the software in an economical and scheduled manner. Component-based development uses the
components that are encapsulated set of standardized data and methods for processing data.
• Extreme programming: This software development method uses a specific structure to accelerate and
simplify the software development process. The extreme programming (XP) team develops application
for a particular purpose and are not worried about adding unasked functionalities that can decelerate the
development process, thereby making the progress of the software development simple and regularizing
designing and testing.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-25
V11.0
Unit 1. Introduction to software development & application security
Uempty
• Agile development: This software development method uses a description of development with short
development iterations to reduce risk.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-26
V11.0
Unit 1. Introduction to software development & application security
Uempty
Adherence to secure software development
principles
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Information security triad comprises of
– Confidentiality
– Integrity
– Availability
Availability
Confidentiality
Information
Security
Integrity
Information Security Triad
© Copyright IBM Corporation 2016
Figure 1-14. Adherence to secure software development principles
Notes:
Information security triad
Application security primarily addresses the integrity part of the triad in an effort to maintain the accuracy of
data. It also addresses the availability of the system by protecting against malware that may waste system
and network resources. The following figure shows information security triad:.
• Confidentiality: The application must ensure that access is only given to authorized people or
processes. The program (application) must also ensure that each user only gets access according to
their privilege level. The application should limit the use of the application and data to the intended
purposes and covert channels and object reuse.
• Integrity: The application can often prevent the corruption of data through proper edit checks and
controls. The application must also be written to ensure the correct and complete processing of
transactions. Malware may specifically target the integrity of the data.
• Availability: The whole purpose of an application security is to make it easy for users to access data
correctly. The application must be written in such a way as to provide the information promptly. Even
when applications are used as intended if the application is not optimized for the number of users it may
fail.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-27
V11.0
Unit 1. Introduction to software development & application security
Uempty
Web application security principles
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Web application security principles include:
–
–
–
–
–
–
–
–
–
–
–
Validate all input and output
Fail secure (closed)
Fail safe
Make it simple
Defence in depth
Only as secure as the weakest link
Security by obscurity
Do not cache secure pages
Industry standard encryption
Monitor third party code vendors for security alerts
Validate all data. Users data should be bound checked
© Copyright IBM Corporation 2016
Figure 1-15. Web application security principles
Notes:
Web application security principles
• Validate all input and output: Both input and output should be validated. Only allow data known as
valid.
• Fail secure (closed): It is a design principle that make it compulsory that should anything fail, it should
fail in such a way that it is secure rather than failing and leaving everything open. An example is a
firewall. Should the firewall software crash, all traffic should be disallowed rather than allowed?
• Fail safe (opened): It is a design principle that obligates that if a part of a system fails then the failure
does not cascade to break down the entire system, in particular the access of the rest of the system.
Thus, the system fails open is good for availability, but not confidentiality.
• Make it simple: If a security system is too complex, it will either not be used or users will find ways to
bypass it. An example is a rigorous password check where users have to write passwords down because
they are too complex.
• Defence in depth: The system should be designed in such a way that if one part of the system fails to
catch the security breach the other part will, thereby providing defence in depth.
• Only as secure as the weakest link: Attackers will search for the link that can be easily breached in
order to exploit it, therewith the system security is as strong as the weakest link.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-28
V11.0
Unit 1. Introduction to software development & application security
Uempty
• Security by obscurity: While obscuring information may give you some time, you are not actually
protecting the information, just relying on luck that someone won’t find it. This is not an acceptable
security position.
• Do not cache secure pages: When data is transmitted via HTTPS, the client side should not be
configured to store the data.
• Industry standard encryption: Such as AES should be used whenever possible.
• Monitor third party code vendors for security alerts: All applications and operating system have
security bulletins that must be reviewed on a continual basis.
• Validated all data. User data should be bounds checked: All partner data (third party) should be
verified against known values.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-29
V11.0
Unit 1. Introduction to software development & application security
Uempty
Application design & development
security
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Application design & development security include:
–
–
–
–
–
–
Secure design methodology
Secure development methodology
Security testing
Change control and configuration management
Certification and accreditation
Vulnerability response plan
© Copyright IBM Corporation 2016
Figure 1-16. Application design & development security
Notes:
Application design & development security
• Secure design methodology: It include list required skills by developers, attack surface analyst, threat
modelling and security design review.
• Secure development methodology: It should be used such as: assessment tools, check-in reviews, peer
reviews, and version control of updates/configuration changes.
• Security testing: It should have predetermined criteria and testing methodology. Tools for security testing
include: Static Scanners, Coverage tools, Control coverage, Fuzzing and Penetration testing. Exceptions
and error conditions should push the application past the data norms.
• Change control and configuration management: For the application and the operating system, the
application will reside or must be defined and moved from know-good to known-good.
• Certification: It is the technical evaluation of the system and the risk it poses to the environment
accreditation is management’s acceptance of the risk of operating system in the environment. C & A
process must be clearly defined.
• Vulnerability response plan: It is the vendor sided of patch management. When a vulnerability is reported
how is it handled? What validation is in place? What is the update preparation, update notification, and
update dispersal process? How does the user community find out? Is your local CERT/FIRST team
notified? Are your customers notified directly or via CVE?
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-30
V11.0
Unit 1. Introduction to software development & application security
Uempty
Environment and controls
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• It is essential to address the following while dealing with environments and controls:
–
–
–
–
–
–
–
Security of the environment
Physical and logical separation of duties
Separation of production and development environment
Retention of key personnel/knowledge
Documentation of programs/systems/errors handling
Security and monitoring of off hours access
Preventing social engineering
© Copyright IBM Corporation 2016
Figure 1-17. Environment and controls
Notes:
Environment and controls
• Security of the environment: It is controlled via physical controls.
• Physical and logical separation of duties: It can be achieved with separate software interfaces.
• Separation of production and development environments: It is performed by creating and using
development sandbox with permissions limited to the development team.
• Retention of key personnel/knowledge: It is possible using good hiring practices.
• Documentation of programs/systems/error handling: It is done by development team will aid next version
development and vulnerability management.
• Security and monitoring of off-hours access: It is another physical security control coupled with the
access control systems, it will help in the event of an investigation.
• Preventing social engineering: Through routine awareness training, ensure that everyone is trained on
proper procedures. Following established security procedures. Following established security procedures
is an excellent way to combat social engineering.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-31
V11.0
Unit 1. Introduction to software development & application security
Uempty
Essence of secure software development
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Additional software protection mechanisms include:
–
–
–
–
–
–
–
–
–
–
–
Cryptography
Access controls
Validation of external components
Backup and redundancy controls
Training
Transaction controls
Malicious code control
Documentation and common program
Testing and evaluation
Mobile code controls
Data contamination controls
© Copyright IBM Corporation 2016
Figure 1-18. Essence of secure software development
Notes:
Additional software protection mechanisms: There are many protection mechanisms that are available
and necessary for software. This list is not exhaustive, but it meant to indicate some of the more common
mechanisms, and prompt the candidate to remember and study others.
Cryptography: Cryptography can be used in a variety of ways: note the cryptography domain deals with
authentication as well as the hiding of data. Cryptography has been then the process of decryption, when the
file is being used, will scramble the virus code, preventing intended operation (this does not guarantee the
integrity of the program operation, but will, at least, subvert the attack). Cryptography can be used for
availability as well. If data files are protected by encryption, then they may be made available in unsecured
environments, where confidentiality might otherwise be compromised. Calculating a hash of a program or
patch may also prevent the malicious or accidental alteration of the software.
Access controls: Access controls may be installed at many levels, but not all are appropriate for all types of
threats. Application level can have numerous access controls installed, but this can open data to attacks by
those working outside the specific application environment. Recall the issue of multiple paths to obtain
information, and ensure that access can be effectively controlled.
Validation of external components: The software that is used by the organization should be check.
Off-site & contract development: Any development by third parties does not transfer the risk. All business
processes and contractual obligations must have reviewed.
Purchased APIs and libraries: Any tools required to run applications should be a part of the change control
process.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-32
V11.0
Unit 1. Introduction to software development & application security
Uempty
Open source: Open source software is often misunderstood as “free” software. The important concept is that
with the source code for open source software is available to the user or purchaser, whereas with most
software only the executable or object code is available to the purchaser. The security implications are
debated, but most analysts feel that the ability for large numbers of users to examine the code results in
systems with fewer unanticipated vulnerabilities. A related concept is that of full disclosure. Again, there is
debate as to whether, once a vulnerability has been discovered, it should be reported only to the vendor, or to
the public at large. Historically, it can be shown that vendors take longer to deal with vulnerabilities that have
not been disclosed. Phases of open source code development/release:
• Vendor makes source code available for examination, modification, extension.
• Various users may find and fix bugs.
• Attackers may find vulnerabilities.
• Disclosure (full/partial) is related.
Backup and redundancy controls: Providing backups of operating system and application software
ensures programs are available in the event of an outage or system crash. Purchased source code, or extra
copies. Should be kept in escrow. Redundancy controls, in relation to backups and hardware redundancy, are
covered more fully in the purchaser of proprietary commercial software. Therefore, where the ability to update
and extend the software is critical to an enterprise, special arrangements may be made to have a third party
hold a copy of the source code, in order to have the resource available in the event of failure or bankruptcy on
the part of the software vendor or developer (the availability of source code is another argument used to
promote open source software).
Training: All staff on the development team for design, coding and testing must be trained to assume
security is built-in and not bolted on.
Transaction controls: For databases controls such as: Database rollback, checkpoint/restart must be
addressed. Application controls of field initialization & reuse, temporary file / workspace clearing, and variable
clearing must be reviewed.
Malicious code control: Subtypes include change detection, activity monitoring, and known signature
scanning. These fundamental types of detection systems are somewhat but not precisely similar to intrusion
detection system (IDS) as mentioned in the access control domain. Note that these malware detection
categories were proposed by Fred Cohen in 1983, and that all subsequent malware detection schemes have
been variations. For example, a statistical-based, anomaly or rule-based, and signature-based IDS are
present in change detection, scanner, and activity monitor system respectively.
Documentation and common program controls: The “common” system components; that is, those used
by everyone, have a particularly strong requirement for security. However, it is a truism that “everybody’s job
is nobody’s job.” Therefore, do not neglect protection of these items. Note that while user documentation
provides little risk, system documentation may indicate areas of weakness or suggest points of attack.
Therefore, system documentation, and configuration information, should be subject to controlled access.
Testing and evaluation: Testing is a necessary, but very complex art. Therefore, it may be much easier to
ensure proper program development to begin with than to set up a testing regimen that will identify all
possible error situations. Note that testing is a part of certification, and also change management and control,
seen elsewhere in this domain.
Mobile code controls: Sandbox is the security control mechanism for mobile code. Its main functionality is
protection and testing. In this mechanism an unverified program/software is executed in a controlled
environment thereby making the host computer free from any harmful consequences. Sandbox is somewhat
similar to virtualization in terms of the specific functionality of providing highly secured and restrained
environment. The program executed in sandbox can have setting for limiting the memory size and processor
usage. This limitation allows the web server to terminate the program and generate an error log when the
executed program exceed the allowed limits, thereby safeguarding the safety of server functionality.
Data contamination controls: Some forms of output control can be used in isolation, but many rely on
comparisons with input data. Erroneous input may be either deliberately malformed, as an attack, or the
result of simple mistakes or carelessness. Both forms can be detrimental to correct operation or results.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-33
V11.0
Unit 1. Introduction to software development & application security
Uempty
Auditing and assurance mechanisms
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Auditing and assurance mechanisms are:
– Information integrity
– Information auditing
– Malware assurance
© Copyright IBM Corporation 2016
Figure 1-19. Auditing and assurance mechanisms
Notes:
Auditing and assurance mechanism
Assurance is important in all domains of security, but it is particularly important in regard to systems and
application development. Since much of the protection for information system resides in software utilities and
functions, it is vital that we have full confidence that the software systems are operating as designed and
intended.
• Describe policies and techniques for system reliability and assurance.
• Identify special development situations and relevant mechanisms.
• Describe operations and acquisition management considerations and practices.
• Describe and understand change management principle.
Information integrity: Remember to provide checks for the integrity, consistency, and sanity of both input
and output.
• Use cyclic counts for transactions, batch totals, hash totals, and balances.
• Compare what was processed against what was supposed to be processed.
• Check input accuracy, perform data validation and verification checks.
Information auditing: Auditing is important in a number of areas of security. It is not always easy to
determine what information is relevant to the processing of a particular system. In addition, it would be very
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-34
V11.0
Unit 1. Introduction to software development & application security
Uempty
easy, in auditing the flow of information, to bury yourself in data. These points should guide you on areas to
attend to.
• Log and audit any action that could affect the release of sensitive information.
• Level and type of auditing is dependent on the features of the installed software and the sensitivity of the
data.
• Information on types of activities and who took the action.
Malware assurance: Effective and workable policies are one of the best protections against malware of all
kinds. Most malware is permitted entry, or even aided, by users running software from questionable sources.
When reviewing anti-malware systems, remember what the basic purpose is. Make the effectiveness of the
system a prime consideration. Do not place undue emphasis on ease of use or pretty system interfaces that
mask a lack of basic operational effectiveness. As noted previously, automated scanning is a good first line of
defence, but is much less effective than manual scanning. Manual scanning should be done regularly as a
backup. Regularly check that your anti-malware systems are, in fact, operating. Many users like to rely on
disinfection to deal with malware: it seems a quick and easy solution. Note, however, that disinfection is not
always effective, and, in many cases, is not possible. The preferred and safer method of dealing with
malware is to detect all malware found, and replace infected items from a safe backup source. Activity
monitoring and auditing is particularly important on communication systems. Monitoring of open ports and
outgoing email may not prevent you from becoming infected, but it will often point out that you are infected or
have a RAT or zombie installed. Make specific checks of your operating system, server, and protective
software. Keeping patched and updated is an important part of malware protection. Patch management is,
itself, an important matter and will be discussed shortly. Note the mention of egress scanning. Certain types
or volumes of outbound traffic may indicate the presence of malware, even if regular scanning software does
not detect it on individual machines. Now that you have learnt the basic concepts of programming language &
application security, let’s discuss in detail about - input validation & sensitive data - in the next section, which
arises due to bad software design and can create potential problem.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-35
V11.0
Unit 1. Introduction to software development & application security
Uempty
Checkpoint
IBM ICE (Innovation Centre for Education)
IBM Power Systems
1. Application security refers to the countermeasures applied to:
A.
B.
C.
D.
Web applications
Mobile applications
Databases
All the above
2. Application security controls are applied during which stage:
A.
B.
C.
D.
Inception of application development
Testing of application
Rollout of application
Post user feedback
3. Which of the following is an interpreted language?
A.
B.
C.
D.
Python
Java
C++
XML
4. The oldest and most common application security vulnerability is:
A.
B.
C.
D.
Denial of service
Input attack
Garbage collection
Buffer overflow
© Copyright IBM Corporation 2016
Figure 1-20. Checkpoint
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-36
V11.0
Unit 1. Introduction to software development & application security
Uempty
Checkpoint
IBM ICE (Innovation Centre for Education)
IBM Power Systems
5. From the below mentioned list, which one is not an application security principle?
A.
B.
C.
D.
Defence in depth
All assets shall have a designated owner
Fail safe
Fail secure
6. Should all user input and output should be checked to ensure application security?
A. True
B. False
7. The concept of “need to know” means:
A.
B.
C.
D.
All the users should have privilege access
Top management should have privilege access
IT team members should have privileged access
Access to be given as per requirement
8. Ten steps of SDLC are:
A. Initiate, Conceptualize, Plan, Analyse Requirement, Design, Develop, Integrate & Test, Implement, Operate &
Maintain, Dispose
B. Initiate, Conceptualize, Analyse Requirement, Plan, Design, Develop, Integrate & Test, Implement, Operate &
Maintain, Dispose
C. Initiate, Conceptualize, Plan, Analyse Requirement, Design, Implement, Develop, Integrate & Test, Operate &
Maintain, Dispose
D. All of the above
© Copyright IBM Corporation 2016
Figure 1-21. Checkpoint
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-37
V11.0
Unit 1. Introduction to software development & application security
Uempty
Checkpoint
IBM ICE (Innovation Centre for Education)
IBM Power Systems
9. Which of the following are compiled languages?
A.
B.
C.
D.
C++
Perl
XML
Python
10. Which of the following utilities translates the program statement by statement?
A.
B.
C.
D.
Assembler
Compiler
Interpreter
Active X
© Copyright IBM Corporation 2016
Figure 1-22. Checkpoint
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-38
V11.0
Unit 1. Introduction to software development & application security
Uempty
Unit summary
IBM ICE (Innovation Centre for Education)
IBM Power Systems
After completing this unit, you should be able to:
•
•
•
•
•
Get an overview of traditional and modern programming languages
Understand the software development life cycle and its components
Gain insight on the need of application security
Identify the secure application development principles
Comprehend secure software development methodology
© Copyright IBM Corporation 2016
Figure 1-23. Unit summary
Notes:
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
1-39
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Unit 2. Introduction to input validation &
sensitive data
Overview
This unit provides an insight on input validation and sensitive data
How you will check your progress
• Checkpoint
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-1
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Unit objectives
IBM ICE (Innovation Centre for Education)
IBM Power Systems
After completing this unit, you should be able to:
• Get an overview of input validation
• Understand the importance of sensitive data
© Copyright IBM Corporation 2016
Figure 2-1. Unit objectives
Notes:
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-2
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Introduction to input validation &
sensitive data
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Input validation requires the understanding of the following:
– Basics of input validation
– Necessity of input validation
– Implementation of input validation
© Copyright IBM Corporation 2016
Figure 2-2. Introduction to input validation & sensitive data
Notes:
Introduction to input validation & sensitive data
Input validation and sensitive data play a vital role in securing web and database applications. This unit
details input validation vulnerability category that can be a threat to application security and can be executed
through various methods like buffer overflow, cross-site scripting, SQL injection, & canonicalization attack. In
addition, sensitive data will make you aware of the processes of sensitive information access, sensitive data
in storage, information disclosure, and data tampering.
Basics of input validation
Input validation is a method in which the correctness of the user’s input data is confirmed prior to sending to
the server for processing of the request(s). The sole responsibility of input validation lies on the shoulders of
application developers who try to figure out ways to stop input validation attack. These attacks are executed
by embedding malicious strings in form fields, query string, cookies, and HTTP headers. Now the question
arises: can input validation attacks be completely stopped. The answer to this question is little tricky, and its
difficulty can be understood by considering programmer’s perspective in mind. For a software developer who
is creating the code to validate input, it is challenging since there may or may not have finite and unique
answer to consider the input to be valid within or across applications, as there can be multitudinous ways
user can input data that do not violate any coded rules but may be regarded as malicious. Moreover, there is
no single definition of malicious input that can help developer to guard against security breaches.
Aggravating to the situation, risk of exploitation of the input is dependent on what task the application
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-3
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
performs with the input. For instance, do applications utilize your data stored in your machine in the form of
cookies etc., or do applications offer data services to provide data for you to utilize.
Necessity of input validation
Modern world in completely reliant on web or database applications for information. The security of
information is one of the most important aspect for a developer, who tries to make the developed software as
robust and secured as possible. Out of many ways in which application security can be breached one most
common method that malicious coders utilize to exploit the system’s database is by way of altering and
searching vulnerabilities in application by manipulating input that the users send and receive. Carefully
crafted input is the most important tool for a hacker to access application databases, modify it, and can even
damage it. For the aforementioned reason, input must be tested and verified in order to countermeasure
malicious characteristics that hacker inject into input. Because of that, application security attacks can be
safeguarded from malicious intent through accurate input validation. Sound validation of input is an efficient
method to countermeasure buffer overflow, cross site scripting, SQL injection, and canonicalization attacks.
Implementation of input validation
In order to make input validation unfailing, you must adhere to some of the best practices that can help
mitigate input validation attack.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-4
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Implementation of input validation (1 of 3)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• The most effective countermeasures of input validation are as follows:
– Consider every input to be malicious
– Centralize the input validation process
© Copyright IBM Corporation 2016
Figure 2-3. Implementation of input validation (1 of 3)
Notes:
• Consider every input to be malicious: It is a basic supposition that every programmer must consider,
unless proven wrong, that all input generated by users are harmful. Irrespective of the source of
generation of input whether the input arrives from a user, database, file share, or otherwise, validate all
input if you think the input source is outside the purview of your trust limit. For instance, if you send for
request to any external web service that returns strings, what is the guarantee that the strings do not
have malicious commands embedded in it? Moreover, if multi-applications write to a shared database
and you are reading data from such data source, how can you ensure that the data is safe?
• Centralize the input validation process: It is one of the most essential strategy that every programmer
must pay heed to, and always rely upon, while designing application that is to create input validation and
filtering code in a shared library file rather than on each and every web page. This centralized approach
to input validation process not only ensures consistency in application of rules but also provide a one
place access to modify or rectify the code that can be applied uniformly to each and every program
needing such validation function. Thereby reducing software development effort and future maintenance
issue. Use specifically designed regular expressions and make it global functions that can be accessed
from anywhere within the application to validate individual fields such as emails, postal codes, titles,
names, places, phone numbers, and so forth. An illustration of the centralized approach is shown in the
figure.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-5
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Implementation of input validation (2 of 3)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• The most effective countermeasures of input validation (cont.) are as follows:
– Never rely on client-side validation
– Caution against canonicalization issues
© Copyright IBM Corporation 2016
Figure 2-4. Implementation of input validation (2 of 3)
Notes:
• Never rely on client-side validation: It is an unfailing concept that all programmers must understand
and implement in their coding that is to perform client-side validation as a means to reduce number of
round trips to servers thereby increasing server efficiency, nevertheless never completely relying on
client-side validation and always implementing server side validation as a rule of thumb. The steadfast
reason for server-side validation is that an attacker can bypass client-side validation, terminate client-side
validation function for example by disabling JavaScript, or through any means invented; and if
server-side validation is in place then this strategy will fail and the application becomes doubly secured,
thereby providing in-depth defence.
• Caution against canonicalization issues: It is an important design consideration that every software
programmer must consider that is to avoid designing software that takes input from user for accessing
files through file names as this can be susceptible to canonicalization attack. Rather application should
ascertain which file is needed to be opened for such purpose providing files automatically from the
system. Let’s discuss about the meaning of canonical form and canonicalization. Canonical form is the
simplest, reduced, and most vital form possible without oversimplification, and the process of converting
data to its canonical form is called canonicalization. Data can be represented in a canonical form for
example URLs and file paths, which are prone to exploits due to its simplicity. For instance, file paths can
be in the canonical form such as c:\temp\foo.dat. This file can be very easily attacked using various string
representations like ..\foo.dat, etc. Therefore, caution against canonicalization issue by avoiding file
name input from user. If you indeed need to accept file names input from user, then ensure that it is
strictly formed prior to granting or declining permission to access a particular file, thereby helping in
securing the application from canonicalization breach.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-6
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Implementation of input validation (3 of 3)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• The most effective countermeasures of input validation (cont.) are as follows:
– Undergo strict testing of the input data
© Copyright IBM Corporation 2016
Figure 2-5. Implementation of input validation (3 of 3)
Notes:
• Undergo strict testing of the input data: Strict testing of input data will help developers to control quite
an input validation flaws. The first interaction with the input data is to constrain all known good data that is
what is permitted to get through and restricting invalid data via pattern, type, range, and length matching.
Understand the expectation of your input, and code to meet the expectation so as to receive only the
valid input; try putting the range on the finite data set that is valid in contrast to the infinite data set that is
malicious, thereby invalid. For providing defence in depth, you need to make sure that the code should
also reject known bad input and subsequently sanitize the input. The figure will help you to understand
the technique better.
The detailed approach, description, and trade-off of the strict testing of inputs are as follows:
▪ Constrain input: It is the technique of permitting only good data by filtering allowable input through
format, type, range, and length testing. Enforce the acceptable value for the form fields present on
your application. By checking all the constrains, rejecting all other input as bad data. On the server
side, set character sets in order that you can create canonical form to constrain input in a localized
manner.
▪ Validate data for format, type, range, and length: It is essential to validate data in the input fields
by using strong data types, parameterized stored procedures for data access, and regular
expressions for the string fields, thereby controlling malicious attack to a finer level of security.
Validate all input data in terms of format, type, range, and length, which can make attacking via input
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-7
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
validation more difficult; length testing is most difficult for attackers as they can get through type
checking, but length checking make the attack more tough.
▪ Reject known bad input: It is a less reliable technique but quite effective if used in combination with
allow good data approach. In order to reject bad data, the developed software must know all the
variations of input data that can be considered as malicious or bad. This approach is quite difficult to
achieve as number of ways in which data can be malicious may or may not be finite and even may
not be constant. Range of bad data change over time, nevertheless valid data remains constant
throughout time. For instance, the number of ways to represent characters is numerous for this
reason allow is the preferred approach. In addition, the deny approach is not as rich as allow
approach because bad data like patters that can cause general attack do not remain constant.
▪ Sanitize input: It is the technique in which potentially malicious data is made safe, if the range of
allowed input do not guarantee the safeness of input, by stripping a null character from the end of the
user input string, escaping out values so as to make it a literal, or using URL encoding or HTML
encoding to make data as literal text instead of executable script. To make a valid URI request,
escape out HTML characters and encode URL via HtmlEncode and UrlEncode methods respectively.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-8
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Practical solutions
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• In order to practically validate the input field using the preceding approaches go through the following:
–
–
–
–
–
–
Last name field
Quantity field
Free-text field
User input is not validated in an existing web application
Sanitize input while writing back to the vulnerable website using HTML/URL encoding
Reject script characters that are malicious that come from the vulnerable website
© Copyright IBM Corporation 2016
Figure 2-6. Practical solutions
Notes:
• Last name field: Validate this field by constraining input by permitting strings data in the ASCII range A
to Z and a to z together with apostrophes and hyphens to manage names such as O’Connor and
James-Carter. Also, limit the length of input field to the longest value that are quite likely.
• Quantity field: Validate this field by constraining input by checking range and type of data; for example,
if your input data need a positive integer in the range of 0 to 100 put a range in the validation field and
reject all data that is not an integer and if it is an integer but do not lie in the given range.
• Free-text field: Validate this field by constraining data by permitting letters, spaces, and more generic
characters such as hyphens, commas, and apostrophes and disallowing signs like greater than, less
than, braces, and brackets. Exception can occur if you want that URL links or mark-up tags such as <i>
for italics and <b> for bold to be allowed in the free-text field. In case of URL input ensure that the value
is encoded in order to treat the URL as URL.
• User input is not validated in an existing web application: Ideally, web application checks user input
for each entry point or input field, but there are chances that an existing web application is not validating
their user’s input data, and in such case you need to take makeshift approach to minify the inherent risk
unless a countermeasure is utilized in your web application’s input validation process. There are two
approaches to mitigate the risks, and these approaches do not ensure safe handling of data but provide a
short-term and quick fixes as the following describes:
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-9
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
• Sanitize input while writing back to the vulnerable website using HTML/URL encoding: In this
approach potentially malicious input is made safe by encoding HTML or URL data and output is written
back in a protected format. This is sanitation of input data in action.
• Reject script characters that are malicious that come from the vulnerable website: In this approach
bad input is rejected by using a configurable set of malicious characters. As you have already known that
definition of bad data does not remain constant and is context dependent, so not completely secured.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-10
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Input validation vulnerability
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Input validation vulnerability can be exploited by an attacker using the following methods:
–
–
–
–
Buffer overflow
Cross-site scripting
SQL injection
Canonicalization
© Copyright IBM Corporation 2016
Figure 2-7. Input validation vulnerability
Notes:
Basics of buffer overflow
Buffer overflow is a technique to handle over saturation of buffer memory, which in the current computing
sense is the information stored in the random access memory (RAM). This condition occurs when a program
tries to store more data in a buffer that has less memory space to tackle such data, or when the program tries
to store the data in a memory location outside the bounds of allocated buffer memory space, thereby crashing
the program, corrupting data, executing the malicious code, or breaching security. Buffer overflow is basically
a software vulnerability that can be maliciously exploited by an attacker.
The steps taken to carry out buffer overflow are shown as follows:
1. Entrance: There must be an entrance available to the hacker in order to enter a server such that he can
mess with the stack of buffer by causing an overflow or by adding commands. A Trojan horse is used for
carrying out this step as the Trojan sets up a backdoor software on the server.
2. Smashing the stack: The stack is filled up with meaning less characters and this step is carried out. This
causes the operating systems to crash under normal circumstance as it is no longer in contact of the
course which are necessary for its functions to be performed. The language command of the load
machine can also be smashed by the hacker if he wants to do more.
3. Running commands: An operating system can be commanded by the overflow of the stack buffer.
Command shell can be created by this method. For example: By using “inetd” in UNIX a backdoor can be
created, which can be used to manipulate the session of X-windows. The hacker inserts a code that
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-11
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
works on a same principle as does some communication software. The control of key board, monitor and
the services of mouse can be taken over by the user if this code is used.
If a UNIX server is being attacked by creating a backdoor, the attacker will eventually succeed in carrying out
the attack. A command shell can then be run by the attacker. A program known as ‘wininet.dll’ can be created
by the attacker if the machine to be attacked runs on a window platform. Expertise and patience is required to
carry out this kind of attack as this attack highly complicated and highly technical. Knowledge of the various
languages which are used on a machine and the knowledge of C programming are some pre-requisites to
carry out this kind of attack. Buffer overflow attack is mostly prevalent in programming languages, such as C
and C++, that do not provide any built-in protection against overwriting or accessing of memory location an
array uses and checking for array bounds is not automatically performed, which could have prevented buffer
overflow attack. There is a technique called address space layout randomization (ASLR) that can protect
against such attack. ASLR uses random address space that can hinder security attacks from an attacker who
try to predict target addresses.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-12
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Buffer overflow (1 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Buffer overflow vulnerability requires the understanding of the following:
– Detailed description of buffer overflow
– Affected environments of buffer overflow
© Copyright IBM Corporation 2016
Figure 2-8. Buffer overflow (1 of 2)
Notes:
Detailed description of buffer overflow
A web application can be affected by buffer overflow attack; which attackers wield for spoiling the
implementation stack. Attackers can successfully take control of a computer by running a specially created
malicious code that is input by sending it to the web application. Discovery of buffer overflow vulnerability in
an application is quite a difficult task; and after its discovery, the exploitation of the application is even more
arduous. Despite the odds, ingenious attackers have identified and managed buffer overflow attack in an
astonishing array of components and products quite successfully. Flaws of buffer overflow can also be
present in application server or web server that governs the dynamic or static nature of a web application.
The web application that uses graphics library to render images are also prone to buffer overflow attacks.
Custom web applications used by organizations can also suffer from buffer overflow vulnerability though the
threat to security is less likely owing to the fact that there are quite a few hackers who will try to exploit the
defects of specific web application. Therefore, in custom web application discovery of buffer overflow risk is
quite less and if the vulnerability is discovered the threat to the application is reduced as error messages and
source code for the application are rarely available to the attacker.
Affected environments of buffer overflow
The susceptibility of buffer overflows is present in nearly all identifiable web application, application server,
and web server environment. The exception to this is in J2EE and Java environments in which buffer
overflows threat can have no effect or is immune to such attacks, though Java Virtual Machine (JVM) can be
affected by buffer overflows.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-13
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Buffer overflow (2 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Buffer overflow vulnerability requires the understanding (cont.) of the following:
– Determination of buffer overflow vulnerability
– Protection from buffer overflow attack
© Copyright IBM Corporation 2016
Figure 2-9. Buffer overflow (2 of 2)
Notes:
Determination of buffer overflow vulnerability
Keep yourself informed with the latest error or bug reports for libraries and server products that are being
used by you to make safe and certain it is not vulnerable. In case of custom-built web application, you must
review the code via view source code and check whether inputs through HTTP request could be able to deal
with randomly large data, if yes then the application is immune else vulnerable.
Protection from buffer overflow attack
You must analyse your developed software in terms of memory management so as to ensure that arbitrarily
large input data is perfectly handled to control buffer overflow. The latest bug report that you have obtained to
determine the vulnerability of the server product or software libraries you are utilizing should be referred, and
always upgrade the patches developed by the original software vendor to fix those issues immediately. You
can at regular time intervals scan your web application for buffer overflow fault by running specific scanners
that are easily available through the Internet. When the fault is found fix those fault by appropriated size
checking of inputs and rid of operational issues and denial of service attack.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-14
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Cross-site scripting (1 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Cross-site scripting vulnerability requires the understanding of the following:
– Basics of cross-site scripting
– Detailed description of cross-site scripting
© Copyright IBM Corporation 2016
Figure 2-10. Cross-site scripting (1 of 2)
Notes:
Basics of cross-site scripting
Knowing about cross-site scripting (XSS) is not like knowing about the scripting languages and the various
categories of scripting thereof. Knowing about cross-site scripting is like understanding the potential threat
this malicious attack can create in web applications. Principally, cross-site scripting is an application security
vulnerability in which attackers inject a client-side code into vulnerable web pages that are browsed by users.
This attack can help attackers to evade access control mechanisms like the same-origin policy (SOP), which
empowers a web browser to allows code present in one web page to access data in a second web page with
a condition that both web pages should have the same origin like port number, hostname, and URI scheme,
thereby preventing a malicious code located on one web page to gain access to sensitive data on another
web page via that page’s document object model (DOM). The aftermath of the evasion may limit from a trifle
annoyance to a substantial security breach depending upon the strength of the application security
implemented on the website as well as on the degree of the sensitive data that is being stored in it.
Application security breach is mainly executed by attackers using XSS or SQL injection attack, which arises
in the software due to blemished or unsophisticated coding and by not sanitizing the input. XSS attack’s main
focus is to steal session cookies through session hijacking, thieve password by attempting credential theft,
forge data transmitted to user so as to gain monetary advantage by deception, and thieve private, financial, or
other sensitive data whose disclosure imply loss of identity, money, and privacy.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-15
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Detailed description of cross-site scripting
Cross-site scripting vulnerability is present in all those web applications in which software developers either
do not validate the input entered by users in the web pages containing forms or the validation is not strong
enough to filter the encoded malicious code. In the former case, the web applications take any input, whether
correct or incorrect, from users. While in the latter case, the filtration mechanism needs to be updated to
undergo rigorous validation. The vulnerability in the security of application allows the applications, in any
case, to utilize input data without any hindrance to generate result(s) as output. Now, an attacker searches
the Internet to find the vulnerable websites that do not validate user’s input using some tools. Once the
vulnerable website is found the attacker with malevolent intention sends malicious code usually in the form of
a script to inject it into the user’s input data.
The input data together with script gets executed, thereby making the attack successful. The end-user’s web
browser has no means to know the trustworthiness of the script and allows it to run. The browser assumes
the script has arrived from a trusted source, but in actuality it is an untrustworthy, different website script
originated from dissimilar origin and should not be trusted without strong validation. Also, the attackers can
use encoding technique such as Unicode to make the malicious code look unsuspicious to the user, so it
becomes quite difficult to detect using filtering techniques. Though, if the encoding is not performed an easy
detection is to find tags written using the symbol < >.
Nevertheless, there are numerous variations that are used by attackers that do not use tags. Moreover,
attacker can use ingenious ways to trick web applications to relay malicious code, which developers could not
be able to filter out and so there is a high probability of it being overlooked. In addition, XSS attack can
propagate thorough embedded active content such as JavaScript, VBScript, ActiveX (OLE), Flash, etc. You
should know that XSS attacks are of four types: reflected, stored, DOM injection, and hybrid.
In reflected type, scripts that are injected is reflected off the web server like in search result, error message,
or other response. And the script is sent by the attacker to the users by way of other web server, email
containing deceptive form for users to input, or via malicious link to be clicked by the users. In stored type,
scripts that are injected is stored on the targeted web server like in visitor log, message forum, database, or
comment section. The stored type XSS is highly dangerous in blogs, forums, or content management system
(CMS) where users will see a large number of inputs from other users.
In DOM injection, the web application’s JavaScript variables and codes are altered instead of HTML
elements. And finally there is hybrid type, it is the blend of all three types. All these XSS attack type compel
the user to erroneously executes the XSS code. Therefore, the outcome of an XSS attack is same and is
independent of the types, rather only difference lies in the way payload reaches the server.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-16
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Cross-site scripting (1 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Cross-site scripting vulnerability requires the understanding (cont.) of the following:
– Affected environments of cross-site scripting
– Determination of cross-site scripting vulnerability
– Protection from cross-site scripting attack
© Copyright IBM Corporation 2016
Figure 2-11. Cross-site scripting (1 of 2)
Notes:
Affected environments of cross-site scripting
The susceptibility of cross-site scripting is present in nearly all identifiable web application, application server,
and web server environment.
Determination of cross-site scripting vulnerability
Web servers and web applications in case of the occurrence of any unexpected condition returns error web
page displaying a message such as HTTP 404 – page not found, HTTP 500 – internal server error, etc.
These error pages can help you to determine the vulnerability of the website or web servers. What you need
to do is to find whether the error web pages reflect any data that users have entered such as the accessed
URL then you can very well make out there is a vulnerability of cross site scripting attack. The tried and tested
method to determine vulnerability in an application is to scan and review the codes of the developed software
that takes input in the form of HTTP and generates output in the same form. Although, XSS flaw is difficult to
identify and remove from the web applications, nevertheless there are tools available that can help scan a
website for these flaws, though superficially.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-17
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Protection from cross-site scripting attack
The best way to protect a web application from XSS attacks is ensure that your application performs
validation of all headers, cookies, query strings, form fields, and hidden fields (i.e., all parameters) against a
rigorous specification of what should be allowed. The validation should not attempt to identify active content
and remove, filter, or sanitize it. There are too many types of active content and too many ways of encoding it
to get around filters for such content.
We strongly recommend a ‘positive’ security policy that specifies what is allowed. ‘Negative’ or attack
signature based policies are difficult to maintain and are likely to be incomplete. Encoding user supplied
output can also defeat XSS vulnerabilities by preventing inserted scripts from being transmitted to users in an
executable form. XSS has a surprising number of variants that make it easy to bypass blacklist validation.
Watch out for canonicalization errors. Inputs must be decoded and canonicalized to the application’s current
internal representation before being validated. Make sure that your application does not decode the same
input twice. Such errors could be used to bypass whitelist schemes by introducing dangerous inputs after
they have been checked.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-18
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
SQL injection (1 of 3)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• SQL injection vulnerability requires the understanding of the following:
– Basics of SQL injection
– Detailed description of SQL injection flaws
© Copyright IBM Corporation 2016
Figure 2-12. SQL injection (1 of 3)
Notes:
Basics of SQL Injection
Structured query language (SQL, pronounced sequel) is one of the foundation in database handling. You
must know that data needs to be saved in your memory drive, the how and where part is handled by
database, which is governed by the 5th generation query language know by the name of SQL. Once you are
familiar with the utility of SQL in programming then you can understand the essence of SQL injection. It is
basically injecting or inserting SQL query in dynamic database handling mechanism and help in inserting,
deleting data in a database. At present, the most famous and common method of hacking is carried out by
SQL injections. The data base of any website can be accessed by an unauthorized person by using this
method. All the detail of the data base can be acquired by the attacker. Below are some of the base in which
this type of attack can be carried out:
• Log ins can be surpassed
• Secret data can be accessed
• Website content can be modified
• My SQL server can be shut down
SQL injection is a code injection technique, used to attack data-driven applications, in which malicious SQL
statements are inserted into an entry field for execution for example to dump the database contents to the
attacker. SQL injection must exploit a security vulnerability in an application’s software; for instance, when
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-19
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or
user input is not strongly typed and unexpectedly executed. SQL injection is mostly known as an attack
vector for websites but can be used to attack any type of SQL database. SQL injection attacks allow attackers
to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or
changing balances, allow the complete disclosure of all data on the system, destroy the data or make it
otherwise unavailable, and become administrators of the database server.
Detailed Description of SQL Injection Flaws
Injection flaws allow attackers to relay malicious code through a web application to another system. These
attacks include calls to the operating system via system calls, the use of external programs via shell
commands, as well as calls to backend databases via SQL that is SQL injection. Whole scripts written in Perl,
python, and other languages can be injected into poorly designed web applications and executed. Any time a
web application uses an interpreter of any type there is a danger of an injection attack.
Many web applications use operating system features and external programs to perform their functions.
Sendmail is probably the most frequently invoked external program, but many other programs are used as
well. When a web application passes information from an HTTP request through as part of an external
request, it must be carefully scrubbed. Otherwise, the attacker can inject special (meta) characters, malicious
commands, or command modifiers into the information and the web application will blindly pass these on to
the external system for execution.
SQL injection is a particularly widespread and dangerous form of injection. To exploit a SQL injection flaw, the
attacker must find a parameter that the web application passes through to a database. By carefully
embedding malicious SQL commands into the content of the parameter, the attacker can trick the web
application into forwarding a malicious query to the database. These attacks are not difficult to attempt and
more tools are emerging that scan for these flaws.
The consequences are particularly damaging, as an attacker can obtain, corrupt, or destroy database
contents. Injection attacks can be very easy to discover and exploit, but they can also be extremely obscure.
The consequences can also run the entire range of severity, from trivial to complete system compromise or
destruction. In any case, the use of external calls is quite widespread, so the likelihood of a web application
having a command injection flaw should be considered high.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-20
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
SQL injection (2 of 3)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• SQL injection vulnerability requires the understanding (cont.) of the following:
– Affected environments of SQL injection
– Illustration of SQL injection
© Copyright IBM Corporation 2016
Figure 2-13. SQL injection (2 of 3)
Notes:
Affected Environments of SQL Injection
Every web application environment allows the execution of external commands such as system calls, shell
commands, and SQL requests. The susceptibility of an external call to command injection depends on how
the call is made and the specific component that is being called, but almost all external calls can be attacked
if the web application is not properly coded.
Illustration of SQL injection
A malicious parameter could modify the actions taken by a system call that normally retrieves the current
user’s file to access another user’s file for example by including path traversal “../” characters as part of a
filename request. Additional commands could be tacked on to the end of a parameter that is passed to a shell
script to execute an additional shell command. For instance, “; rm -r *” can be appended to the existing
command to execute SQL injection attack; the command removes all directories and their content recursively.
SQL queries can also be altered by appending in the where clause constraints such as “ OR 1=1” to access
data from the attacked database.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-21
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
SQL injection (3 of 3)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• SQL injection vulnerability requires the understanding (cont.) of the following:
– Determination of SQL injection vulnerability
– Protection from SQL injection attack
© Copyright IBM Corporation 2016
Figure 2-14. SQL injection (3 of 3)
Notes:
Determination of SQL injection vulnerability
In order to determine the vulnerability of your web application to SQL injection, you need to scan the entire
software and find instances where application code calls using any kind of syntax such as structured queries,
fork, exec, system, etc. making requests to databases, interpreters, or some external resources. Understand
that there are numerous ways in which an external commands or SQL codes can be executed. Therefore,
software developer must review their program to find instances where input from an HTTP request can
succeed in making unsolicited calls to the system. The steps that attackers use to carry out SQL injection will
help you to implement robust application security technique. These steps are depicted as follows:
1. Finding vulnerable website: The website which are vulnerable to external hacking can be found out by
using a google application known as google dork list. Google searching tricks is used by google dorks to
find out the vulnerable website.
2. Checking the vulnerability: The single quote (‘) is used to check the vulnerability of the website. This
single quote is added at the URL and then it is processed. There should be no space between the last
digit of the URL and the single quote. The website is not vulnerable if the new URL which has been
entered directs to the same page or shows that the page is not found. If an error which is associated with
the query of SQL is shown, then the website is vulnerable.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-22
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Protection from SQL injection attack
In order to make your application immune to SQL injection vulnerability try not to access external interpreters
as much as possible. And if the same functionality is essential, then use programming language specific
libraries to perform the task as these libraries do not require the involvement of the interpreter, thereby
eliminating the necessity to make system calls or write shell command to provides the same feature but
create vulnerability. For the case where access to backend database is essential, it is advisable to validate
the data so that no malicious content can bypass it. Also, try to structure requests in such a way that all the
input parameters are treated as data and not as executable codes.
By adhering to the preceding protection mechanism you can of course mitigate the vulnerability involved in
making external calls, but never eliminate the treat. So make sure that you always, as a rule of thumb,
validate your input data rigorously. Second and most important countermeasure that you must undertake is to
make your application free from the need to use admin rights and provide only those permissions that are
essential to do the operation.
Therefrom, you will not provide functionality in your application that uses root to run a web server or
DBADMIN to access a database. This will protect your application from attacker who can misuse admin right
via SQL injection to read, write, or delete your database content. Use reusable components produced by
OWASP Filters project to stop SQL injection and application level firewall, CodeSeeker from OWASP.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-23
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Canonicalization (1 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Canonicalization vulnerability requires the understanding of the following:
– Basics of canonicalization
– Affected environments of canonicalization
© Copyright IBM Corporation 2016
Figure 2-15. Canonicalization (1 of 2)
Notes:
Basics of Canonicalization
Canonicalization is the technique of reducing something to the simplest and most significant form possible
without loss of generality so as to manage ambiguity. The simplicity implicate vulnerability. The simplest form
can be easily and accurately guessed, which can then by exploited by an attacker for malicious intent. For
this reason, web application developer has to ensure that the developed software has built-in safety
mechanisms to deal with canonicalization issues from URL encoding to IP address translation.
Unicode encoding is a technique that is used to store characters using many bytes. Attackers can conceal
malicious code using Unicode and inject this code into user input data, accordingly accomplishing umpteen
attacks.
Apart from this, traditional data transfer technique uses GET or POST method to send input data from client
to server. In the GET method data is transmitted in the query section of a URL, while in the POST method
data is transmitted in the HTTP headers. URL encoding thus transmits encoded data complying with URL
syntax such as RFC1738 defines URLs and RFC2396 defines URIs. Since URL encoding technique allows
virtually any data to be passed to the server, you must develop your web application taking utmost
precautionary measures to deal with malicious attack.
For instance, use HTTP POST method instead of HTTP GET method to submit forms data; this will avoid
appending sensitive data to URL. If transmitting data to the server using URL is required, then limit the size
and data type of the input data and disallowing text data through strict validation code and sanitize the URL
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-24
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
encoded suffix. And, finally perform server-side validation apart from client-side validation for complete
precaution. The countermeasure for canonicalization attack is to create a robust application that is immune to
the Unicode, encoded, and internationalized input.
As a developer, you must understand that just to make your application secure you need not transform it to
the internationalized format, rather it should have security measures to handle cases when malformed or
Unicode input is inserted. Employ strict validation rules to sanitise and ensure submitted data is the correct
type and size
Affected Environments of Canonicalization
Every application environment is susceptible to canonicalization issue.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-25
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Canonicalization (2 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Canonicalization vulnerability requires the understanding (cont.) of the following:
– Determination of canonicalization vulnerability
– Protection from canonicalization attack
© Copyright IBM Corporation 2016
Figure 2-16. Canonicalization (2 of 2)
Notes:
Determination of canonicalization vulnerability
Internally a web application functions via ASCII, Unicode, UTF-16, or ISO 8859-1 encoding technique. The
user of your web application may be utilizing a different locale and an attacker might opt for their character
set and locale with complete freedom. In order to determine canonicalization vulnerability due to diverse input
format scan the web application code to determine if it has internal code page, culture, or locale. If the default
character set locale is not verified it can be one of the following: HTTP POSTS, HTTP GETS, .NET, JSP,
Java, or PHP. In order to protect from this vulnerability, set the character set and asserted language locale as
per the need. If an attacker injects malicious code into the user input via double encoding, then a single check
to determine the input by de-encoding to Unicode values will fail. Determine by double encoding the XSS
code using XSS Cheat Sheet double encoder utility and the match ensures vulnerability.
Protection from canonicalization attack
It is essential that an appropriate canonical from is opted and all input from the users is canonicalized into
that form prior to taking any authorization judgement. Ensure that after completion of the UTF-8 decoding, the
application should perform security checks. Also, make safe and certain that UTF-8 encoding is a correct
canonical encoding for the symbol in denotes.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-26
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Sensitive data (1 of 3)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Sensitive data exposure vulnerability requires the understanding of the following:
– Basics of sensitive data
– Detailed description of sensitive data
© Copyright IBM Corporation 2016
Figure 2-17. Sensitive data (1 of 3)
Notes:
Basics of sensitive data
Sensitive data are those data that comprises of varied information including personal details such as
identification name, permanent account number, aadhaar number, parent’s name, date of birth, etc.; financial
details including credit card data, bank account details such as bank name, bank account number, IFSC
code, user name, and password for internet banking, etc.; organizational details including the details of
organization, customers, employees, students, or patients; and even pertaining to classified information or
matters affecting national security. Protection of sensitive data is essential to prevent identity theft, financial
theft, or national security breach and must be protected by laws, policies, and regulations. Because of the
vulnerability that sensitive data possesses it is subject to diverse threats.
Data can be exposed in three generic ways: social engineering, phishing, and intrusion. In social engineering
swindlers collect your sensitive data by shamming themselves as representative of authentic organization
and use your sensitive data for fraudulent purpose. In phishing attackers use ingenious methods to exact
your sensitive data over network by sending an email with attachments or links that can ask you to input your
sensitive information. Intrusion on the other hand search for vulnerabilities in your computer to gain access to
your sensitive files containing sensitive data.
Attacks attempting to see or alter sensitive data can target networks and data centres. Some of the most
important threats to sensitive data includes: sensitive data access, sensitive data in storage, sensitive data
exposure, and data tampering.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-27
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Detailed description of sensitive data
In day to day administration organization collect large amounts of personal data. Out of these collected data a
large part of the data is not considered sensitive as these data are easily available from the Internet through
search engines that can generate your data from LinkedIn, Facebook, Twitter, or any social networking sites,
etc. The information that are stored in this sites include your name, telephone number, address, date of birth,
educational details, professional details, and preferences.
None of these information can be considered sensitive data as the breach of these data will not harm you or
cause financial loss. Nevertheless, organisation can ask for sensitive data such as user Permanent Account
Number, Aadhaar Number, Bank Account Number, Legal Information, etc. that can be considered sensitive.
Data are considered sensitive if it is protected by government law or organizational policy. The term
"sensitive" is descriptive. Sensitive data may fit into various classifications based on the legal requirements
and use.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-28
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Sensitive data (2 of 3)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Sensitive data exposure vulnerability requires the understanding (cont.) of the
following:
– Examples of sensitive data
– Breach of sensitive data
© Copyright IBM Corporation 2016
Figure 2-18. Sensitive data (2 of 3)
Notes:
Examples of sensitive data
Personal data
• Permanent Account Number (PAN)
• Aadhaar Number
• Driving Licence Number
• Passport Number
• Visa Number
• Mother’s maiden name
Financial data
• Debit Card Number
• Credit Card Number
• Card Expiry Date
• Card Verification Value (CVV) Number
• Credit Details
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-29
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
• Tax Information
Government protected data
• Student information & grades
• Medical, health, or psychological information
Organization protected data
• Passwords
• Human subjects research data
Public or non-sensitive data
• Telephone directory information
• Last four digit of bank account, debit/credit card number
Breach of sensitive data
Breach of sensitive data could lead to crime and can have negative impact on its owner. Person with unlawful
intention could harm, tarnish, or bankrupt the owner if the sensitive data get compromised. Leak of personal
data could result in fraud or identity theft, leak of financial data could result in monetary loss, and leak of
organization protected data can result in larceny. Those who are holding the sensitive data is bound by law to
protect its integrity and security. Perpetrators are liable for civil remedies and in extreme cases subject to
criminal penalties.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-30
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Sensitive data (3 of 3)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Sensitive data exposure vulnerability requires the understanding (cont.) of the
following:
– Vulnerability of sensitive data exposure
– Example of sensitive data exposure
– Protection of sensitive data leakages
© Copyright IBM Corporation 2016
Figure 2-19. Sensitive data (3 of 3)
Notes:
Vulnerability of sensitive data exposure
Sensitive Data Exposure occupies the 7th spot in the list of OWASP Top 10 Web Application Vulnerabilities. It
deals with the threats associated with the unauthorized handling of business sensitive information. Business
Data can broadly be categorized into two groups, public data and protected data. While public data can be
accessed by the common users, protected data are usually confidential to a specific group of people. Any
business, irrespective of its nature and scale, will have some confidential data points that must be
safeguarded from appearing in the public domain. Such sensitive information is intended to be used by a
handful of recipients and any unauthorized access may lead to serious consequences. Unauthorized data
access occurs due to a web application's inability to adequately protect sensitive information from being
disclosed to attackers. This type of vulnerabilities is usually very difficult to exploit. However, if an attack for
stealing sensitive information manages to succeed, then the impact can be really severe. The most common
flaw that results in leakage of sensitive information is the absence of a proven encryption technique to
safeguard the application. Improper key generation and management is another common factor that
contributes to such vulnerabilities. But even when an encryption method is implemented, applications may
still be vulnerable to sensitive data exposure due to the usage of weak encryption algorithms.
Example of sensitive data exposure
How do you ensure that your smartphone does not contain sensitive data before reselling it to someone else?
The obvious answer is a 'Factory Reset' - which is supposed to wipe out the phone memory and restore the
settings to system default. However, if you are an Android user, then that's not sufficient. If the latest
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-31
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
revelation by a Cambridge University team of research fellows is to be believed, then some Android mobile
devices have a flawed 'factory reset' function which is incapable of fully erasing sensitive user records from
the phone memory. A technically gifted hacker can easily dig up sensitive data - including the login tokens
used to sign in to different online accounts - from a supposedly 'wiped' Android phone. Even when full-disk
encryption is in place, sensitive data still remains in recoverable state. Let's take a closer look at the sensitive
data exposure vulnerability and find out the effective security measures to prevent the occurrence of such a
situation.
Protection of sensitive data leakages
Concerned about protecting your sensitive business data from the prying eyes of hackers. If data integrity is
the first priority, you need OWASP compliant server the organization. The following sections depicts some to
the important leakage protection mechanisms of sensitive data:
1. Enforce strict data encryption: The first step is to categorize and identify the sensitive data points.
Once you have identified the critical data which requires an extra protective cover, the next step would be
to implement a proven encryption technique. Make sure that sensitive data is kept under the wrap of
encryption all the time. Such data should neither be stored nor transmitted in clear text format.
2. Use SSL for user authentication: Protect all authentication gateways on your website with secure
HTTPS (SSL/TLS) protocol. SSL authentication uses the concept of public/private key pair. It means, a
user must supply the corresponding decryption key for gaining access to sensitive data points.
3. Implement strong password hashing algorithm: Password hashing is one of those things that's pretty
straightforward to implement, yet it is taken lightly by a large number of web developers. Hackers can
exploit the weakness in password hashing algorithm to steal sensitive information stored on a web or
application server. Only cryptographic hash functions should be used to implement password hashing.
4. Make use of penetration testing: It's a good idea to make your application undergo a third party
'penetration test'. It will give you a fair insight on how secure the application is. It's a fact that even the
best programmers are susceptible to occasional mistakes. So it makes sense to employ a trustworthy
security expert to review the application for potential vulnerabilities. For best results, the security review
process should ideally continue throughout the life-cycle of application development at a periodic interval.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-32
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Sensitive data access (1 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Sensitive data access vulnerability requires the understanding of the following:
– Basics of sensitive data access
– Protection of sensitive data access
© Copyright IBM Corporation 2016
Figure 2-20. Sensitive data access (1 of 2)
Notes:
Basics of sensitive data access
The useful data generated for specific purpose can be categorized as sensitive and non-sensitive. Sensitive
data are those data whose value is quite important for the user and loss of the sensitive information can lead
to loss of personal information, bank information, and business information, which can lead to loss of money,
privacy, and data leak. So, in order to manage, protect, and secure sensitive data you need to understand the
methodology of how to restrict access to the sensitive data.
For that you need to understand how sensitive data is stored, is the data encrypted before storing, is the data
placed in secure server, and a lot more. Hence, safeguarding access to sensitive data is of utmost priority for
any organization, institutions, and other data management bodies.
Protection of sensitive data access
In order to protect sensitive information access in an organization, take stringent security measures. Allow
authorized personnel to get past the security processes on a need to know basis. Allow the sensitive
information transfer, retrieval, pickup, and delivery only to the authorized personnel. Defend sensitive
information theft and revelation to unauthorized individuals on laptops, desktops, mobile devices, network,
and postal service workstations. The access can be restricted to the unauthorized person for accessing
sensitive information from hardcopy such as printouts, or softcopy using endpoint media such as USB flash
drive, hard disk drive, optical disk, and memory card.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-33
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Protect sensitive information access by encrypting it using advanced encryption algorithm that are stored or
archived. Label sensitive information in electronic or printed material as ‘restricted information’, thereby
restraining others from accessing. In work environment create strong login password and change it once a
month, also lock your computer every time when you leave it is unattended. Track and inventory sensitive
information from creation to destruction.
Before disposal of sensitive information present in hardcopy shred it so that no one else can access it. Some
of the do nots for restricting access to sensitive information include: never disclose sensitive information
without the permission of higher management. Never take out printout of the sensitive information in publicly
accessible printing machine, as it can result in unauthorized viewing of the hardcopy.
Never copy sensitive information unless you can secure the copied data using cryptographic technique.
Never email sensitive data unless it is encrypted using algorithm. Never talk about sensitive information
where other can overhear. Never transmit sensitive information using FAX without the permission from higher
management.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-34
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Sensitive data access (2 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Sensitive data access vulnerability requires the understanding (cont.) of the
following:
– Types of sensitive data
© Copyright IBM Corporation 2016
Figure 2-21. Sensitive data access (2 of 2)
Notes:
Types of sensitive data
Confidential data is used in a general sense to mean sensitive data whose access is subject to restriction,
and may refer to data about an individual as well as that which pertains to a business. Even though they are
often used interchangeably, personal data is sometimes distinguished from private data, or personally
identifiable data. The latter is distinct from the former in that private data can be used to identify a unique
individual. Personal data, on the other hand, is data belonging to the private life of an individual that cannot
be used to uniquely identify that individual. This can range from an individual’s favourite colour, to the details
of their domestic life. The latter is a common example of personal data that is also regarded as sensitive,
where the individual sharing these details with a trusted listener would prefer for it not to be shared with
anyone else, and the sharing of which may result in unwanted consequences.
Confidential business data
Confidential business data is that data whose revelation can ruin or harm the business, its operations, and
hamper its sustainability. Examples of such confidential data include patentable inventions, customer and
supplier data, financial data, trade secrets, and more.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-35
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Classified sensitive data
Classified sensitive data are those data that come in the purview of distinct security categorization
regulations as levied by several national governments, and the disclosure of which may cause harm to
national interests and security. The protocol of restriction imposed upon such data is categorized into a
hierarchy of classification levels in almost every national government worldwide, with the most restricted
levels containing information that may cause the greatest danger to national security if leaked. Authorized
access is granted to individuals on a need to know basis who have also passed the appropriate level of
security clearance. Classified sensitive data can be reclassified or declassified.
In the former case, classified sensitive data is changed to another level and so addressed as reclassified,
while in the latter case it is made available to general public thereby making it declassified. All the two
transformation of the classified sensitive data come into picture contingent on arrival of new intelligence
service or due to some changes of situation.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-36
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Sensitive data in storage
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Sensitive data in storage vulnerability requires the understanding of the following:
– Basics of sensitive data in storage
– Protection of sensitive data in storage
© Copyright IBM Corporation 2016
Figure 2-22. Sensitive data in storage
Basics of Sensitive Data in Storage
As a measure of security do not store sensitive data; since, if there is no sensitive data stored in the digital
format imply there is no fear of its stealing and so no loss. This is not what is in practice in reality, else the
study of application security will lose its importance. If storage of sensitive data is of utmost priority and
necessary as in the case for financial institutions, health care institutions, schools and colleges, government
and private organisations, and nation’s military, ammunitions, and other secret agencies; then, identify those
crucial sensitive data whose integrity and privacy breach can bring catastrophe to individuals such as bank
account holders, patients and doctors, students and teachers, government and private employees, as well as
to nation that can create potentiality for war.
Once the most crucial sensitive data is obtained you can implement avant-garde security measures to
encrypt, protect, and secure your data, thereby ensuring that even if the data gets compromised it will have
no use to the attacker and transform it from substantial loss to no loss.
For instance, if you are storing passwords only for authentication purpose, do not store it directly rather store
the hash value of table in a database in order to provide secured login to users to your web application.
Saving hash values generated using cryptographic hash functions for passwords as input can help protect
the sensitive passwords from misuse.
Cryptographic hash functions are otherwise known as one-way hash functions that generate one-way hash
value that cannot be reversed except after extensive brute force attack which is practically infeasible.
Therefore, one cannot obtain the original data from the hashed value in feasible amount of time. If the
database containing hashed table of passwords is compromised, then this data security breach cannot
disclose the password information even after re-hashing to obtain clear text data, thereby safeguarding its
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-37
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
integrity and security. Some of the hash functions include message digest algorithm (MD5) and secure hash
algorithm (SHA-1, 2, or 3). On the other hand, if you are storing sensitive data such as credit card numbers of
customers, do not store it directly or hash it as the hashing will not help; since, you need the number for
verification not comparison unlike the case of passwords where the user input password is hashed and
compared with the hash table to get a match to grant access or mismatch to deny access. Instead, use a
strong cryptographic technique either symmetric key cryptography, which uses the same key for encryption
and decryption; or asymmetric key cryptography, which uses one key for encryption and another key for
decryption. For securing credit card number as the case is use symmetric key cryptographic technique such
as Triple DES (3DES) to encrypt the sensitive data.
Protection of sensitive data in storage
In order to protect sensitive data in storage follow the succeeding points:
• Utilize restricted access control list (ACL) to store sensitive data
• Utilize latest and advanced encryption algorithm to encrypt sensitive data
• Utilize role-based and identity-based authorization to access sensitive data
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-38
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Information disclosure (1 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
•
Information disclosure vulnerability requires the understanding of the following:
– Basics of information disclosure
– Information disclosure vulnerability
– Information disclosure prevention
– Example attack scenarios
© Copyright IBM Corporation 2016
Figure 2-23. Information disclosure (1 of 2)
Notes:
Basics of information disclosure
Sensitive data disclosure is one of the most challenging issue that can be prevented by using encryption,
secure socket layer technology, etc. The severity of the data revelation is completely reliant on the sensitivity
of the data being revealed. For instance, revelation of bank information could cause financial loss, personal
information could cause identity theft, and user credentials could mean loss of privacy to the social
networking sites, or other websites where user name and password is mandatory to login to the website. For
a server-based application path disclosure can reveal the structure of the web application and can be a threat
for information security breach. Information disclosure is influenced by the following:
• Security flaw: If the stored sensitive data is not encrypted then it exposes security weakness and is
susceptible to security attack. Therefore, always store sensitive data by encrypting it using a strong
encrypting algorithm, strong key generation and management methodology, and strong password
hashing technique. Flaws in a browser is easy to notice but difficult to abuse in a big scale. While flaws
on the server side is difficult to discover owing to the access limitation and is equally difficult to exploit.
• Attack vectors: Cyber attackers or attack vectors generally do not try to decrypt cryptographic data
directly rather they perform man-in-the-middle attack, thieve cryptographic keys, steal clear text
information, or do something else to breach security either from the user’s browser of from the data
during transfer process.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-39
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
• Threat agents: Include both internal as well as external threats that can gain access to sensitive data
present in your cloud or system, during the transmission process, or directly from client’s web browser.
• Business impacts: Loss of sensitive data can impact business as it can damage business reputation,
imply penalty from customers whose data is breached, and consequently result in decline of business.
• Technical impacts: Loss of sensitive data can impact technology shortcomings. The data which should
be protected is compromised due to frequent failures of security system of an organization or individual.
Information disclosure vulnerability
It is essential that you should understand the importance of sensitive data and take extra precautionary
measure while storing it in digital format. If the sensitive data is present in your storage device and can be
accessed through the network or needs to be transmitted to external source for specific purpose, then you
need to protect your data and minimize the vulnerability of information disclosure. In order to safeguard your
sensitive data from exposure keep in mind the following points:
1. Never store sensitive data in clear text format including the backup for long term
2. Never transmit sensitive data in clear text format either internally or externally
3. Always use advanced and latest cryptographic algorithms to encrypt sensitive data
4. Use strong cryptographic keys and key management technique to prevent data breach
5. Ensure the presence of browser security headers or directives while transmitting sensitive data
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-40
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Information disclosure (2 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
•
Information disclosure vulnerability requires the understanding (cont.) of the following:
– Information disclosure prevention
– Example attack scenarios
© Copyright IBM Corporation 2016
Figure 2-24. Information disclosure (2 of 2)
Notes:
Information disclosure prevention
It is essential to use advanced data protection methods, strong cryptographic algorithm, and secure socket
layer to prevent accidental disclosure of information, malicious attack by hacker, or thwarting attack by
insider. For all sensitive data, do the following:
1. Encrypt all sensitive data in stored form and during transmission process
2. Avoid unnecessary storage of sensitive data and throw away if not needed
3. Always use advanced encrypting algorithm, strong key, & sound key management practice
4. Use specifically designed password protection algorithm to store and manage passwords
5. Disable caching for web pages and autocomplete on forms that gather sensitive data
Example attack scenarios
1. A database application stores passwords of customers without salting the hashes. An attacker is able to
access the password file due to a flaw during file upload and could be able to read all the unsalted
hashes via rainbow table. The countermeasure for this attack is to use salted hashes to store sensitive
data and disallow breach of data security by threat agents.
2. A web application uses automatic database encryption algorithm to encrypt sensitive data, the credit card
numbers of customers, and stores it on the database. The same web application also allows automatic
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-41
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
decryption and retrieval of data from the database, thereby permitting an attacker to use SQL injection
attack to disclose in clear text the sensitive information, which needs to be protected. The method to
countermeasure this attack is to use public key to encrypt the sensitive data through front-end application
automatically, and private key to decrypt the same data, which is only permitted through the back-end
application by an authorized personnel.
3. A web application is not using secure socket layer to authenticate its web pages. This application security
vulnerability can be exploited by an attacker who monitors the network traffic and can thieve user’s
session cookies. The cookie can then be misused to hijack the user’s session using the cookie replay
attack, thereby allowing the sensitive data of the user to get compromised. The countermeasure for this
attack is to make your web application secured by using SSL technology.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-42
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Data tampering (1 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
•
Data tampering vulnerability requires the understanding of the following:
– Basics of data tampering
– Data tampering protection in URL
© Copyright IBM Corporation 2016
Figure 2-25. Data tampering (1 of 2)
Notes:
Basics of data tampering
Tampering of data is one of the challenges that the contemporary world is facing. You have already
understood the basics of sensitive data, its storage, and its susceptibility to network eavesdropping. In this
section you will go through the data tampering and how to protect sensitive data from being tampered once it
is transmitted.
Data tampering protection in URL
It is sometimes required by a legitimate website to transmit sensitive data from one page to another or from a
client to the server machine and vice versa using URL. This is something that needs special care in order to
protect the sensitive data in transit by way of URL, as the data can be accessed by the attacker. Transmission
of data through URL can be completed using GET or POST method in the <form> tag or via the key/value
pair. You can protect sensitive data from tampering using various techniques including input validation
technique. For instance, in a database query it is required that integer input be sent via the URL. By verifying
the data for it type as integer the input can be verified for its correctness. The input validation method can of
course help prevent the unexpected behaviour of the program but in no way help defend against data
tampering. So, how to safeguard data against tampering attack; the following topic discusses in brief about
how to prevent data tampering:
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-43
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Data tampering (2 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
•
Data tampering vulnerability requires the understanding (cont.) of the following:
– Data tampering protection in database
– Data tampering protection through hashing
– Data tampering protection through encryption
© Copyright IBM Corporation 2016
Figure 2-26. Data tampering (2 of 2)
Notes:
Data tampering protection in database: If you want to reference a row in a database without leaking
information for example how many rows are present in the database, you can simply store a randomly
generated unique identifier in an extra column and reference that instead.
Data tampering protection through hashing
Data tampering can be detected using a hashing algorithm. For example, when an id variable of a user is
passed from one web page to another as the user keeps on browsing the website the web application
expects the id to remain immutable. Each successive browsed page can verify the value of the id variable for
mutation by calculating, transferring, and processing the hash value of the data together with the id value.
Re-hashing and matching the hash value with the previous web page hash value can convey the application
whether the data is being tampered by any malicious user or not. If both the hash value matches, then the
data is not tampered else something fishy is going on. There is one gimmick to the preceding procedure that
is the id variable is visible to the attacker, nevertheless the attacker could not be able to know the secret and
the hashing algorithm for generating the hash value in order to tamper with the data.
Data tampering protection through encryption: Sensitive data can be protected by using symmetric keys
that do not disclose the actual data value. The idea is similar to hashing function, nonetheless uses
symmetric keys for encryption and decryption of sensitive data. You can also use a secure encryption library
to encrypt sensitive data. When sensitive data is sent via URL, an encode technique is used in the URL to
encrypt the value of the input id and it is received on the recipient system and subsequently decode
technique is used to decrypt the URL to retrieve the original data.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-44
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Checkpoint
IBM ICE (Innovation Centre for Education)
IBM Power Systems
1. Where to protect data from tampering?
A.
B.
C.
D.
Data in transit
Data at rest
Data in process
All of the above
2. Which of the following is a way to prevent data tampering?
A.
B.
C.
D.
Encryption
Penetration testing
SQL injection
Cross-site scripting
© Copyright IBM Corporation 2016
Figure 2-27. Checkpoint
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-45
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Checkpoint
IBM ICE (Innovation Centre for Education)
IBM Power Systems
3. What is buffer overflow?
A.
B.
C.
D.
Software security vulnerability
Software sanitization problem
Programming error
None of the above
4. What is the primary motive of input validation?
A.
B.
C.
D.
To ensure integrity of data
To ensure security
To ensure availability
To ensure confidentiality
© Copyright IBM Corporation 2016
Figure 2-28. Checkpoint
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-46
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Checkpoint
IBM ICE (Innovation Centre for Education)
IBM Power Systems
5. Which of the following is not a sensitive information?
A.
B.
C.
D.
Personal data
Financial data
Public data
Business data
6. Penetration testing is technique of
A.
B.
C.
D.
Protecting of sensitive information
Identifying the potential vulnerability of an application
Fixing the vulnerabilities of an application
None of the above
© Copyright IBM Corporation 2016
Figure 2-29. Checkpoint
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-47
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Checkpoint
IBM ICE (Innovation Centre for Education)
IBM Power Systems
7. In order to safeguard sensitive data from exposure
A.
B.
C.
D.
Store sensitive data in clear text format
Transmit sensitive data in clear text format
Use strong cryptographic keys
None of the above
8. Encryption is a technique to prevent
A.
B.
C.
D.
Data tampering
Disclosing the Information
Classification of Information
Penetration testing techniques
© Copyright IBM Corporation 2016
Figure 2-30. Checkpoint
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-48
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Checkpoint
IBM ICE (Innovation Centre for Education)
IBM Power Systems
9. Name of an individual or business is
A.
B.
C.
D.
Confidential information
Personal information
Protected information
Public information
10. What is CVV?
A.
B.
C.
D.
Card verification value number
Card virtual verification number
Card visa verified number
Credit verification number
© Copyright IBM Corporation 2016
Figure 2-31. Checkpoint
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-49
V11.0
Unit 2. Introduction to input validation & sensitive data
Uempty
Unit summary
IBM ICE (Innovation Centre for Education)
IBM Power Systems
After completing this unit, you should be able to:
• Get an overview of input validation
• Understand the importance of sensitive data
© Copyright IBM Corporation 2016
Figure 2-32. Unit summary
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
2-50
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
Unit 3. Introduction to authentication &
authorization
Overview
This unit provides an insight on authentication and authorization
How you will check your progress
• Checkpoint
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-1
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
Unit objectives
IBM ICE (Innovation Centre for Education)
IBM Power Systems
After completing this unit, you should be able to:
• Get an overview of authentication process
• Understand the importance of authorization
© Copyright IBM Corporation 2016
Figure 3-1. Unit objectives
Notes:
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-2
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
Introduction to authentication &
authorization (1 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Authentication & authorization vulnerability requires the understanding of the following:
– Basics of authentication
– Detailed description of authentication
© Copyright IBM Corporation 2016
Figure 3-2. Introduction to authentication & authorization (1 of 2)
Notes:
Introduction to authentication & authorization
A Web application’s specific vulnerabilities should dictate the technology you use to defend it. Often, it is best
to employ generic countermeasure concepts first to help ensure that you choose the technology best suited
to your needs rather than one that claims to counter the latest hacking technique. The following figure shows
many points within a system that might require protection.
Basics of authentication
Authentication is the process of proving or affirming someone or something as authentic, thereby verifying
the truth of the claim, which is made by the person or about the thing. If you are creating a login page for
users to access your web application by entering username and password then you need to implement the
basic application security feature to identify, authenticate, and authorize the user for particular access rights.
Make your application security robust by handling denial of service attack and brute force attack. This is quite
essential to safeguard the sensitive data of the user as well as the organization from prying eyes, malicious
users, attackers, or cyber criminals. Also, ascertain that your application provides the functionality of digital
identity verification, safe transmission mode for rendering credentials, and specific authorization to
authenticated users. Authentication process need separate access to public and restricted areas, ID
accounts and resources that cross trust boundaries, identify accounts that service or administer the
application, ensure that user credentials are encrypted and stored securely, specify the ID for authenticating
with the database. Construction mechanism is to store passwords as digests, return minimal error information
with authentication failures, and do not use HTTP header information for security purposes.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-3
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
Detailed description of authentication
Now, you should regard the authentication mechanism from the outlook of a developer: check all web pages
by default and authenticate access to the web pages that need the usage of resources, barring those that are
public; use two-factor authentication, other impregnable authentication, or any similar strategy that render
protection against the disclosure of username plus password; check the non-echoing of password when
typed by user, mandate the entry of password for log in, encourage the usage of passphrases, block
commonly opted passwords and weak passphrases, do not prevent the creation of long passphrases or
highly complex passwords, obligate the entry of the three fields: old, new, and confirm password to
successfully change password in the forgot password link, do not reveal the current password in recovery
path or forgot password function rather use mobile push, soft token, or an offline recovery mode, do not send
the new password in clear text, encrypt account password using strong encryption algorithm so that it cannot
be breached by brute force attack within feasible timeframe, transport user input credential using appropriate
encryption link, check there is no default password such as admin/admin that can allow access to application
or its components, check that your system can be configured to forbid the reuse of configurable number of
previous passwords; check the server-side authentication controls are enforced apart from the client-side
authentication; check all authentication controls fail securely to restrict log in by hackers; check that the
secondary functionality such as forgot password, update profile, lost or disabled token, interactive voice
response (IVR), or help desk that can help revive access to the account is made as secure as the basic
authentication process; check that enumeration of information cannot be executed by any means through
forgot account details, password reset, or login functionality; check request throttling is present to stop
automated attacks; check that authentication credentials for external applications are stored in password
table using one-way hashing in a protected database situated in a secured location; check the presence of
mutually exclusive hard and soft lock for accounts and the breach of one should not reset the other; check the
presence of strong secret questions or knowledge-based queries to protect the system; check that in order to
operate application-specific sensitive information according to the risk factor is allowable via transaction
signing, two factor authentication, adaptive or step up authentication, or re-authentication mechanism as a
compulsory means; check that the average response time remains similar in the case of failure or success of
all authentication challenges; check the exclusion of passwords, API keys, and secrets in the program code;
check the usage of proven secure authentication mechanism whenever users are permitted to authenticate
the web application; check inaccessibility of administrative interfaces to non-trustable parties. Failure to do so
can result in violations of privacy, undermining of authorization and accountability controls, and hijacking of
administrative accounts.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-4
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
Introduction to authentication &
authorization (2 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Authentication & authorization vulnerability requires the understanding (cont.) of the following:
– Affected environments of authentication issues
– Determination of authentication vulnerability
– Protection from authentication attack
© Copyright IBM Corporation 2016
Figure 3-3. Introduction to authentication & authorization (2 of 2)
Notes:
Affected environments of authentication issues
The susceptibility of authentication problems is present in nearly all identifiable web application, application
server, and web server environment.
Determination of authentication vulnerability
It is not that uncommon to find imperfections in the authentication process of a web application. Rather flaws
occur more frequently through the adjunct authentication functions such as update of account, creating
secret questions, providing remember me feature, and logout, timeout, as well as password management
functionalities. In order to determine the vulnerability of a web application for authentication defects scan the
entire software either manually or using automated tools to verify whether authentication mechanism is
properly executed meeting all the secured authentication principle. Review and test the code to check
whether authentication and its ancillary functions are accomplished as per the standard guidelines.
Protection from authentication attack
As a programmer you can protect your web application by means of secured storage of credentials using
hashing or encrypting, and secured communication by means of secure socket layer (SSL). You must rid of or
limit the use of custom-built cookies to provide the functionality for authentication with the exception of single
sign on (SSO) solutions, which uses remember me type functionality where a user has to enter the login
credentials only once per session to access multiple services; and Federated Identity (FID) solutions, which
uses the feature of storing of credentials on home organization known as identity provider to manage identity
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-5
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
of users. Further, you must utilize multiple factors and right strength to provide single authentication
mechanism, but ensure its immunity from replay and spoofing attacks. Also, make your login process initiate
from an encrypted as well as from the second web page with new and fresh session token to defend against
session fixation, credential or session stealing, and phishing. Whenever privilege level changes or
authentication becomes successful, then you must regenerate a new session. Check that every page has
logout link and must have the auto functionality to destroy all session states from server-side and cookies
from client-side, also do not ask for confirmation as users have a tendency of closing the pop-up window
instead of successfully logging off by clicking the OK button.
It is essential that strong secondary authentication functionality such as password reset, answers for
question, etc. are treated as credentials and should be stored using one-way hashing method to prevent
information disclosure attack. Verify the old password when user request for password change. Credentials
that can be tampered should not be used such as DNS reference, reverse DNS reference, IP address,
address range mask, headers of referrers, etc.
Be cautious to send one-time password (OTP) to registered email or mobile for resetting of passwords and
use random numbers for limited time access. Send follow-up mail or message on registered mobile once the
password is reset. Take extra care while changing the email of the registered user by sending mail to the
previous email for confirmation to perform the alteration.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-6
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
Network eavesdropping (1 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Network eavesdropping vulnerability requires the understanding (cont.) of the following:
– Basics of network eavesdropping
– Detailed description of network eavesdropping
– Example of network eavesdropping attack
© Copyright IBM Corporation 2016
Figure 3-4. Network eavesdropping (1 of 2)
Notes:
Basics of network eavesdropping
Networks eavesdropping is a passive attack in which attacker gathers network traffic and reads data
transmitted from client to server and vice versa. The motive of this attack is to execute credential theft by
thieving password, accomplishing sensitive data theft by stealing bank account details, hijacking session by
stealing session cookies, etc. In addition, attacker can install network monitoring hardware or software
through physical access to the network. Further, attacker can create unreliable network such as public Wi-Fi
for users to access and get exploited. In order to countermeasure from network eavesdropping, the quality of
authentication and encryption mechanism should be good so as to prevent the leakage of data. Access
control can be implemented by using security protocol.
Detailed description of network eavesdropping
Network eavesdropping, otherwise known as network sniffing, is a network layer attack in which
eavesdropper capture packets transmitted between networks and try to read data in a hope to find secret
passwords, session tokens, and essential credentials. For this purpose, the attacker can use the sniffer tools
like protocol decoder, analyser, or stream reassembling to capture and collect the data packets. The
conditions that need to be met for effective sniffing in various environments include: LAN environment with
hubs – it is a highly vulnerable situation in which eavesdropping attack can be carried out quite easily as hub
being a network repeater keeps duplicates of every network frame received to all ports, thereby making the
attack simple and do not require any other condition fulfilment. LAN environment with switches – it is a less
vulnerable situation in which sniffing attack can be carried out only if a preliminary exploitation like ARP spoof
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-7
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
attack is successful, since a switch by default only transmits a frame to the addressed port. Therefore, some
mechanism or configuration of the switch is necessary that will duplicate the traffic or redirect the network
packets to an evil system. This makes the evil system work like a router between the client and the server
and making it possible to sniff the exchanged packets. WAN environment – it is also a vulnerable situation in
which evil system must become router for eavesdropping that can be achieved through DNS spoof attack of
the client machine.
Example of network eavesdropping attack
Network eavesdropping vulnerability is not so easy to discover and can be recognized by the result of the
preliminary condition or by inducing the evil system respond to a fake request directed to its IP, but with the
MAC address of a different machine. The network eavesdropping become easier when hub is used on the
local area network topology as you are already read because hub repeats all traffic received on one port to all
other ports. The attacker can capture all traffic and access sensitive data by using protocol analyser.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-8
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
Network eavesdropping (2 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Network eavesdropping vulnerability requires the understanding (cont.) of the following:
– Determination of network eavesdropping vulnerability
– Protection from network eavesdropping attack
© Copyright IBM Corporation 2016
Figure 3-5. Network eavesdropping (2 of 2)
Notes:
Determination of network eavesdropping vulnerability
Network security issues continue to persist in wireless as well as wired network despite the huge investment
in security measures to make application security unfailing. Eavesdropping attack is exceedingly harmful as it
is very difficult to determine whether the attack is taking place in the network or not. When users connect to a
network assuming it to be secured, they unknowingly input sensitive data such as bank account details,
passwords, likes and dislikes, browsing habits, etc. to an eavesdropper. The simplicity and persistency of the
network eavesdropping attack makes it even more vulnerable and its security needs multi-aspect approach.
Things that needs to be considered in order to determine and mitigate the network eavesdropping attack is
explained as follows:
• Awareness – information technology experts should promote the awareness of information security and
present beneficial practices in organizations, because lack of awareness can be a dangerous security
issue. You must think about the application you are going to use before you connect to a public wireless
network. Be aware whether the public Wi-Fi network provider is using strong encryption to transmit
sensitive data. If they are not, then you might caution yourself against using the network for entering
sensitive data as your data security can be compromised by a malicious eavesdropper. If you have
discovered the vulnerability of the public network, then you should spread the message to others.
• Encryption – the best defence against network eavesdropping is encryption. You can make attacker fail
in his attempts by only using the system and application with strong encryption. Nevertheless, it is not a
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-9
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
panacea due to the following two reasons: first, encrypted data has suffered from dual pronged attack.
The processing speed of computer increases exponentially adhering to Moore’s law and tools for security
becomes more advanced and smarter thereby making the attack more difficult. Also the state-of-the-art
technology and faster processing speed makes the attacker succeed in breaching encryption through the
use of advanced password-cracking methodology such as rainbow tables to decipher passwords in
seconds or via the use of brute force attack that can crack password in a practicable time, which was
once considered infeasible within human lifespan even by super computers. Second, regrettably
encryption is not used or is not the default option for many applications owing to performance criteria,
thereby resulting in breach of information security.
• Network Segmentation - from a security point of view the default situation, anything can access
anything, is a weak consideration in the network world. For instance, is there any use for a salesperson’s
laptop to gain access to company’s human resource network. The answer is no, why a general user’s
device need access to a specific network. If proper and formal segmentation of the network is performed
and access rights granted, then network vulnerability including eavesdropping can be mitigated. Formal
segmentation of the network is mandatory to countermeasure against numerous threats that prevail in
the contemporary computing world.
• Network Access Control – make network eavesdropping very difficult to accomplish for an attacker by
preventing any unauthorised users to gain access to your network at the outset. Block physical access to
the premises where the network is setup through security checks if the network is wired. Use Network
Access Control (NAC) in case the network is wireless in order to prevent unauthorized user to breach
information security. NAC is highly reliable and make eavesdropping quite infeasible for an
eavesdropper. Network access control ascertain that full network connection is granted to only trusted
devices and no other device can break the security of the system.
• Physical Security – ensure that there are no network points in the meeting room, waiting room, lobby,
etc. that can be accessed by visitor, which can provide complete access to corporate network. These
kind of flaws provide an easy means to connect to corporate network and thieve data by eavesdropping
or accomplish other malicious task, therefore physical security is a must and should not be ignored.
Protection from network eavesdropping attack
Network eavesdropping can be controlled by ensuring Remote Access Dial-In User Service (RADIUS)
authentication is activated and data is encrypted with Temporal Key Integrity Protocol (TKIP) using Wired
Equivalent Privacy (WEP) 128-bit encryption. Security protocols divide the network into authentication server,
authenticator, and supplicant such that when looked into a wireless network, the wireless device is the
supplicant, the RADIUS server acts as the authentication server and the authenticator is the Authentication
Protocol (AP). Since there is an involvement of the usage of a RADIUS server in Extensible Authentication
Protocol (EAP) authentication, it acts as a secondary layer of protection. EAP is used between the
authenticator and the supplicant for the communication by a port-based authentication.
EAP verifies a user to be recognized and authenticated so as to grant wireless access by the server, thus
making EAP a user-based authentication and providing enterprise level security to the network. Protected
EAP with Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) authentication can also be
used to increase the level of security. Regular checks should be made for signal leaks outside the building,
and leakage, if present, should be eliminated or reduced by adjusting the transmitter power.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-10
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
Brute force attack (1 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Brute force attack requires the understanding of the following:
– Basics of brute force attack
© Copyright IBM Corporation 2016
Figure 3-6. Brute force attack (1 of 2)
Notes:
Basics of brute force attack
A trial-and-error method used to reveal the secret data like password, useful credentials, or personal
identification number (PIN) is known as brute force attack. In this type of attack automated software is used to
produce a large number of back to back guesses till the desired data is captured. Sometimes Brute force
attack is used by security analysts to check the security of network organization. Attackers use this method to
crack the encrypted data. A brute force attack may also be referred to as brute force cracking. For instance,
dictionary attack is a type of brute force attack that seeks to find the desired values by trying all words present
in a dictionary. Other forms of brute force attack might try commonly-used passwords or combinations of
letters and numbers. An attack of this nature can be time- and resource-consuming. Hence the name "brute
force attack;" success is usually based on computing power and the number of combinations tried rather than
an ingenious algorithm. The following measures can be used to defend against brute force attacks: requiring
users to have complex passwords, limiting the number of times a user can attempt to log in, temporarily
locking out users who exceed the specified maximum number of login attempts. Any kind of password can be
cracked using brute force attack. Every possible combination of letters, numbers or other special characters
are tried in this attack. The complexity of the password determines the duration of time a brute force attack
takes. The computer’s speed is also a determining factor of the time taken to crack the password.
Detailed description of brute force attack
The manifestation of brute force attack can visible in a quite varied manner. Generally, an attacker uses
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-11
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
pre-set data values, input those data values to make several requests to a server, and then analyses the
responses from the server. In order to make the attack more efficient, the attacker may use mutations for
dictionary attack or even utilize the traditional brute force attack technique that comprises of entering case
sensitive/insensitive, special, and alphanumeric characters. It is possible for an attacker to calculate the time
required to make the brute force attack successful through the predetermined data set that has been carefully
created. The calculation is based on the method being used, system’s processing speed, and number of tries
that needs to be undertaken. For instance, brute force attacks are often used for attacking authentication and
discovering hidden content/pages within a web application.
These attacks are usually sent via GET and POST requests to the server. In regards to authentication, brute
force attacks are often mounted when an account lockout policy in not in place. One illustration is, a web
application can be attacked via brute force by taking a word list of known pages, for instance from a popular
content management system, and simply requesting each known page then analysing the HTTP response
code to determine if the page exists on the target server. Second illustration, in regards to authentication,
when no password policy is in place an attacker can use lists of common username and passwords to brute
force a username and/or password field until successful authentication. A password and cryptographic attack
do not try to decode encrypted data rather try a list of words, letters, and passwords to break into the system.
For instance, a dictionary of commonly used passwords or words are cycle through until it gains access to the
account to succeed a brute force attack. A more complex brute-force attack involves trying every key
combination until the correct password is found. Due to the number of possible combinations of letters,
numbers, and symbols, a brute force attack can take a long time to complete. The higher the type of
encryption used such as 64-bit, 128-bit, or 256-bit encryption, the longer it can take. A brute force attack can
always gain access to any account and is completely feasible if ample amount of time is provided. The time
taken for a brute force algorithm to successfully breach an account may range from few seconds to
thousands of years. This time is dependent on the password, the strength of the encryption, how well the
attacker knows the target, and the strength of the computer(s) used to conduct the attack.
Protection from brute force attack
In order to protect from brute force attack vulnerability, it is essential to create application security robust by
allowing the entry of username and password for not more than a specific time, usually three and may even
be five. Also, if the number of attempt exceeds the allowed limit then the software developer can create code
to lock the user from entry into the system or prevent future attempts for a specified set of time. This will help
the application to protect against manual or automated brute force attacks.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-12
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
Brute force attack (2 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Brute force attack requires the understanding (cont.) of the following:
– Detailed description of brute force attack
– Protection from brute force attack
© Copyright IBM Corporation 2016
Figure 3-7. Brute force attack (2 of 2)
Notes:
Detailed description of brute force attack
The manifestation of brute force attack can visible in a quite varied manner. Generally, an attacker uses
pre-set data values, input those data values to make several requests to a server, and then analyses the
responses from the server. In order to make the attack more efficient, the attacker may use mutations for
dictionary attack or even utilize the traditional brute force attack technique that comprises of entering case
sensitive/insensitive, special, and alphanumeric characters. It is possible for an attacker to calculate the time
required to make the brute force attack successful through the predetermined data set that has been carefully
created. The calculation is based on the method being used, system’s processing speed, and number of tries
that needs to be undertaken. For instance, brute force attacks are often used for attacking authentication and
discovering hidden content/pages within a web application.
These attacks are usually sent via GET and POST requests to the server. In regards to authentication, brute
force attacks are often mounted when an account lockout policy in not in place. One illustration is, a web
application can be attacked via brute force by taking a word list of known pages, for instance from a popular
content management system, and simply requesting each known page then analysing the HTTP response
code to determine if the page exists on the target server. Second illustration, in regards to authentication,
when no password policy is in place an attacker can use lists of common username and passwords to brute
force a username and/or password field until successful authentication.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-13
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
A password and cryptographic attack do not try to decode encrypted data rather try a list of words, letters,
and passwords to break into the system. For instance, a dictionary of commonly used passwords or words
are cycle through until it gains access to the account to succeed a brute force attack. A more complex
brute-force attack involves trying every key combination until the correct password is found. Due to the
number of possible combinations of letters, numbers, and symbols, a brute force attack can take a long time
to complete. The higher the type of encryption used such as 64-bit, 128-bit, or 256-bit encryption, the longer
it can take. A brute force attack can always gain access to any account and is completely feasible if ample
amount of time is provided.
The time taken for a brute force algorithm to successfully breach an account may range from few seconds to
thousands of years. This time is dependent on the password, the strength of the encryption, how well the
attacker knows the target, and the strength of the computer(s) used to conduct the attack.
Protection from brute force attack
In order to protect from brute force attack vulnerability, it is essential to create application security robust by
allowing the entry of username and password for not more than a specific time, usually three and may even
be five. Also, if the number of attempt exceeds the allowed limit then the software developer can create code
to lock the user from entry into the system or prevent future attempts for a specified set of time. This will help
the application to protect against manual or automated brute force attacks.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-14
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
Dictionary attack (1 of 3)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Dictionary attack requires the understanding of the following:
– Basics of dictionary attack
© Copyright IBM Corporation 2016
Figure 3-8. Dictionary attack (1 of 3)
Notes:
Basics of dictionary attack
Dictionary attack is the method used to breach the computer security of a password-protected machine or
server. A dictionary attack attempts to defeat an authentication mechanism by systematically entering each
word in a dictionary as a password or trying to determine the decryption key of an encrypted message or
document. This kind of attack is greatly successful because most of the corporate users use common words
as password as it is easy for them to remember.
These ordinary words are easily found in a dictionary, such as an English dictionary. The most common
method of authenticating a user in a computer system is through a password. This method may continue for
several more decades because it is the most convenient and practical way of authenticating users. However,
this is also the weakest form of authentication, because users frequently use ordinary words as passwords.
Antagonistic users such as hackers and spammers take advantage of this weakness by using a dictionary
attack. Hackers and spammers attempt to log in to a computer system by trying all possible passwords and
stopping when the right password is estimated correctly.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-15
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
Dictionary attack (2 of 3)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Dictionary attack requires the understanding (cont.) of the following:
– Detailed description of dictionary attack
© Copyright IBM Corporation 2016
Figure 3-9. Dictionary attack (2 of 3)
Notes:
Detailed description of dictionary attack
The dictionary attack uses a dictionary or possible combinations of words based upon some likely values and
tends to exclude remote possibilities. This dictionary must be flexible enough such that the hacker can add
certain custom words and can conduct a forensics analysis, which is a process in which text documents are
scanned by a software and all the words of that document are added to a dictionary. It may be built on
knowing key information about a particular target such as phone number, family member names, birthday,
etc. The dictionary can be created using patterns seen across a large number of users and known
passwords. Sometimes the passwords set by the users are so simple that they can be easily guessed by the
intruder. The dictionary is more likely to include real words than random strings of characters. The execution
time of dictionary attack is reduced because the number of combinations is restricted to those on the
dictionary list. There is less coverage and particularly good password may not be on the list and will therefore
be missed. Dictionary attacks are not effective against systems that make use of multiple-word passwords,
and also fail against systems that use random permutations of lowercase and uppercase letters combined
with numerals. There are few contrasts between brute force and dictionary attack. In the brute force attack
key space is searched thoroughly while in dictionary attack it is searched from the predetermined and
pre-arranged list. In dictionary attack key space is large and exhaustive while in the dictionary attack key
space is small and have higher success rate in lesser time. The high success rate of dictionary attack is from
the fact that users have a tendency of using short passwords derived from ordinary words or simple variants
obtained, for example, by appending a digit or punctuation character. Dictionary attacks are relatively easy to
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-16
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
defeat, e.g. by choosing a password that is not a simple variant of a word found in any dictionary or listing of
commonly used passwords. You must note that the execution time of dictionary attack decreases if
pre-calculated list of hashes of dictionary words are stored in a database and is used for executing the attack,
thereby providing time-space trade-offs to an attacker to succeed an attack in less time. This pre-computed
hash value once calculated provides capability of cracking password almost instantly, thereby thwarting the
security of an application. If space is a constraint, rainbow table attack can be used by an attacker to perform
the cracking of password in least amount of time.
The rainbow table though uses less space but requires somewhat more lookup time. This type of attack can
be made unsuccessful by using salt in hashes. A dictionary attack can also be used in an attempt to find the
key necessary to decrypt an encrypted message or document. Dictionary attack become unsuccessful
against systems that employ random combinations of uppercase and lowercase letters mixed up with
numerals.
In those systems, the brute-force method of attack in which every possible combination of characters and
spaces is tried up to a certain maximum length can sometimes be effective, although this approach can take
a long time to produce results. Vulnerability to password or decryption-key assaults can be reduced to near
zero by limiting the number of attempts allowed within a given period of time, and by wisely choosing the
password or key. For example, if only three attempts are allowed and then a period of 15 minutes must
elapse before the next three attempts are allowed, and if the password or key is a long, meaningless jumble
of letters and numerals, a system can be rendered immune to dictionary attacks and practically immune to
brute-force attacks. A form of dictionary attack is often used by spammers.
A message is sent to e-mail addresses consisting of words or names, followed by the at symbol @, followed
by the name of a particular domain.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-17
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
Dictionary attack (3 of 3)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Dictionary attack requires the understanding (cont.) of the following:
– Example of dictionary attack
– Protection from dictionary attack
© Copyright IBM Corporation 2016
Figure 3-10. Dictionary attack (3 of 3)
Notes:
Example of dictionary attack
Access to a secret club requires knowing the owner's name, you guess "Sanjay" or "Udit" rather than
"computer" Given the same lock example above, you try a combinations equating to the birthday of the lock
owner or the lock owner's friends and family.
Protection from dictionary attack
Web application can be protected from dictionary attacks by incorporating the following suggestions:
Delayed Response: A slightly delayed response from the server prevents a hacker or spammer from
checking multiple passwords within a short period of time.
Account Locking: Locking an account after several unsuccessful attempts for example, automatic locking
after three or five unsuccessful attempts prevents a hacker or spammer from checking multiple passwords to
log in.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-18
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
Cookie replay attack (1 of 3)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Cookie replay attack requires the understanding of the following:
– Basics of cookie replay attack
© Copyright IBM Corporation 2016
Figure 3-11. Cookie replay attack (1 of 3)
Notes:
Basics of cookie replay attack
A cookie replay attack as the name suggests uses cookie files as the medium of attack. A cookie is a small
text file, for example cookie.txt, rendered by a web application server; available on your web browser like
Microsoft Edge, Internet Explorer, Google Chrome, Mozilla Firefox, Apple Safari, or Opera; stored in your
device’s storage unit such as hard disk drive, solid state drive, or memory card of your smart mobile phone;
contains your identity details for example your cookie id; and serve several purposes including granting of
login without re-entering your login details repeatedly, storing your settings and preferences to provide faster
and better browsing experience, and utilizing your online activity to provide you with your own interest-based
advertising, so you feel your browser to be intelligent that understands your likes and dislikes. The main
purpose of a cookie is to remember your user data for the numerous websites that you visit. A cookie cannot
be executed as a program as is the case for .exe files, therefore cannot transfer viruses to your computer and
can only be read by the server that provided it. An attacker can access your cookie and replay the cookie to
the web server that created the cookie, thereby shamming the server that the cookie has arrived from you but
in reality it has arrived from the attacker. This can permit the attacker to misuse your details to their
advantage. The attacker can cause harm that can range from minor to catastrophic consequence depending
upon the sensitivity of the data that you have saved in the web application server during your profile
registration or update process for the website.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-19
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
Detailed description of cookie replay attack
Each authenticated session is recognized by a distinct session token, which is saved in your browser in the
form of a cookie and is sent to the server at the time of session authentication. Since the cookie containing
the session token is submitted to the web page server every time you make request for the page, the web
application server by the use of cookie smartly recognizes you and allows complete access to your privileged
data. Nevertheless, an attacker who by any means possesses your cookie and replay the cookie to gain
access to your privileged data, thereby succeeding in the cookie replay attack. The web application server is
smart to identify the cookie and grant all privileged data access, but not smart enough to check the malicious
user from gaining access to your own personal information.
The attack can result in impersonation of your identity and execution of fraudulent or unauthorized activities
or transactions. If such is the case, then why not cookie be removed from the browser so that no cookie
replay attack is possible and no breach of security. The reason for the presence of cookies are many. The
stored cookie helps a web application server to be aware that you came back to the website. The main motto
of a cookie is to save your time by helping web application server to remember who you are when you have
registered for any service or product, or when you have personalized the web application experience for your
own sake. When you return to the same website on your next visit, the web application server knows the
information you have requested in your last visit and can showcase you the products or services that you had
desired.
Also, if you want to register for the next product or service all you need is to provide your user credentials
once again and the application will automatically fill the answers that you have already entered. But if you
have never left any personal information or registered with the website, then the web application server only
identifies that someone has arrived to the website with your cookie. Cookie makes the service provider be
more effective in furnishing their services. The service provider can learn what information is important or
useful for their customers and what is not.
The web application service provider can put away the web pages which you don’t use and can focus on your
required information. Cookies can be managed from the browser you are using. You can either choose to
block all cookies, block only third-party cookies, or don’t block cookies option depending upon the features of
the browser you are using. It provides you with the capability to accept or decline a cookie. ASP.NET features
a way to create cookies and automatically checks for their existence on client requests. The cookies created
by ASP.NET can optionally be encrypted using a triple DES scheme supported by the NET framework. You
can also create your own cookies implementation and use it with Forms authentication. Now, the question
arises, can a cookie be edited. It depends upon the features of the browser that you are using. If the browser
provides the features to access cookies, then you can open the cookie by clicking on the file. When a cookie
is opened, it contains short string or numbers and text, which serve as ID card and can be seen and
interpreted by the server that provided it to your browser.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-20
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
Cookie replay attack (2 of 3)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Cookie replay attack requires the understanding (cont.) of the following:
– Detailed description of cookie replay attack
© Copyright IBM Corporation 2016
Figure 3-12. Cookie replay attack (2 of 3)
Notes:
Detailed description of cookie replay attack
Each authenticated session is recognized by a distinct session token, which is saved in your browser in the
form of a cookie and is sent to the server at the time of session authentication. Since the cookie containing
the session token is submitted to the web page server every time you make request for the page, the web
application server by the use of cookie smartly recognizes you and allows complete access to your privileged
data. Nevertheless, an attacker who by any means possesses your cookie and replay the cookie to gain
access to your privileged data, thereby succeeding in the cookie replay attack. The web application server is
smart to identify the cookie and grant all privileged data access, but not smart enough to check the malicious
user from gaining access to your own personal information.
The attack can result in impersonation of your identity and execution of fraudulent or unauthorized activities
or transactions. If such is the case, then why not cookie be removed from the browser so that no cookie
replay attack is possible and no breach of security. The reason for the presence of cookies are many. The
stored cookie helps a web application server to be aware that you came back to the website. The main motto
of a cookie is to save your time by helping web application server to remember who you are when you have
registered for any service or product, or when you have personalized the web application experience for your
own sake.
When you return to the same website on your next visit, the web application server knows the information you
have requested in your last visit and can showcase you the products or services that you had desired. Also, if
you want to register for the next product or service all you need is to provide your user credentials once again
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-21
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
and the application will automatically fill the answers that you have already entered. But if you have never left
any personal information or registered with the website, then the web application server only identifies that
someone has arrived to the website with your cookie. Cookie makes the service provider be more effective in
furnishing their services. The service provider can learn what information is important or useful for their
customers and what is not.
The web application service provider can put away the web pages which you don’t use and can focus on your
required information. Cookies can be managed from the browser you are using. You can either choose to
block all cookies, block only third-party cookies, or don’t block cookies option depending upon the features of
the browser you are using. It provides you with the capability to accept or decline a cookie. ASP.NET features
a way to create cookies and automatically checks for their existence on client requests. The cookies created
by ASP.NET can optionally be encrypted using a triple DES scheme supported by the NET framework.
You can also create your own cookies implementation and use it with Forms authentication. Now, the
question arises, can a cookie be edited. It depends upon the features of the browser that you are using. If the
browser provides the features to access cookies, then you can open the cookie by clicking on the file. When
a cookie is opened, it contains short string or numbers and text, which serve as ID card and can be seen and
interpreted by the server that provided it to your browser.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-22
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
Cookie replay attack (3 of 3)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Cookie replay attack requires the understanding (cont.) of the following:
– Protection from cookie replay attack
© Copyright IBM Corporation 2016
Figure 3-13. Cookie replay attack (3 of 3)
Notes:
Protection from cookie replay attack
You can protect your web application from cookie replay attack by adhering to the application security best
practices. Ensure that authentication cookie is never written to a client machine, therewith making it hard for
an attacker to steal the cookie; no cookie means no thievery. Application is executable via SSL; therefore, a
cookie is never issued over a non-SSL connection.
Enforce absolute expiration of cookie with a specific minute timeout, thereby making the cookie useless after
the passage of allotted time. Use httpOnly cookies so that no one can programmatically intercept or alter
cookie. Even if the above precautions were broken, which is highly unlikely, a malicious user would only have
very short allotted minute window to break the precautions and successfully log in.
The systematic protection and mitigation method for cookie replay attack in ASP.NET are as follows:
• Help protect the application by using Secure Socket Layer (SSL): Configure the web application in
Microsoft Internet Information Services (IIS) so that SSL is mandatory. This will ascertain that the Form
authentication method will never generate cookie over an unsafe network such as non-SSL connection.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-23
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
• Enforce Time to Live (TTL) and absolute expiration: Short TTL, such as 15 minutes, in web
application can reduce the chances of cookie replay attack. Avoid the usage of sliding expiration rather
utilize absolute expiration technique.
• Use HttpOnly cookies and forms authentication: Use HttpOnly cookies when creating Form
authentication code. These cookies cannot be accessed through client script and hence mitigate cookie
replay attack.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-24
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
Credential theft (1 of 3)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Credential theft attack requires the understanding of the following:
– Basics of credential theft
© Copyright IBM Corporation 2016
Figure 3-14. Credential theft (1 of 3)
Notes:
Basics of credential theft
In order to understand credential theft, you need to first understand the word credential. A credential is an
evidence of right, ability, or requirement issued to a user by an organization or arbiter. It is basically a
document that attest the truth of specific stated or written facts. For instance, your academic diplomas,
degrees, certificates, identification documents, username, password, etc. are your credentials that testify the
truth of your educational qualification, individuality, and access rights to a system.
In order to steal your identity, money, or gain access to your secured web application, an attacker can thieve
your credentials. Identity theft is a crime whereby attacker try to thieve your private data like passwords, date
of birth or any personal security question and answers in order to impersonate you. This private information
can be used to change your passwords and with the help of these information attacker can gain access the
web application that you have been authorized from the organization.
These credentials can be acquired through various means using the contemporary digital technology.
Credential theft is a threat to the security of web application and must be taken care in the web application
development process from the outset.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-25
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
Credential theft (2 of 3)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Credential theft attack requires the understanding (cont.) of the following:
– Detailed description of credential theft
© Copyright IBM Corporation 2016
Figure 3-15. Credential theft (2 of 3)
Notes:
Detailed description of credential theft
Cloud adoption is revolutionizing the way organizations conduct business. The cloud makes thousands of
enterprise applications available to businesses of all sizes, mostly tailored to the specific needs of each line
of business. And employees can now access business information from any location, from multiple devices,
at any time. Users have the power to be collaborative and productive in more ways with more convenience
than ever before. But with all of the benefits of cloud and software-as-a-service (SaaS), there comes some
risk that should be managed. A recent analysis revealed that the average employee utilizes 28 distinct work
applications. Each of these apps has its own set of user information, often with its own login requirements,
typically a unique set of credentials, i.e. username and password.
Although these credentials are an important part of keeping business information secure, they also represent
weak points in every business’ information security. Every user password represents that final check before
granting access to a business’ information. It also introduces a potential point of access for unapproved users
inclined to pry their way into information systems.
That’s almost 30 vulnerable points of access for each employee. Now multiply that by however many
employees are in your business and you’re looking at a very serious security problem. 500 employees using
30 apps each means 15,000 vulnerable points where malicious parties could exploit this basic security
screen to steal or manipulate precious business information. Having that many weak points is a risk that
businesses simply cannot afford. Luckily, cloud security technology continues to adapt in order to minimize
these types of security challenges. Talk to your cloud vendor about what they are doing to eliminate
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-26
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
passwords and strengthen authentication. If they aren’t utilizing single sign-on to minimize security risk, they
should be. Enterprise network credentials are like the keys to your house: once someone has a copy, they
can enter your space whenever they want.
The more valuable your property, the more motivated the bad guys are to get in. Worse, sophisticated
network intruders leave no trace. Digital assets can be copied, malware can be installed and uninstalled, and
additional accounts can be compromised based simply on the exchange of network packets. While legal
frameworks, policing, and the risks of physical confrontation have made house keys a sufficient form of
security for decades, the mechanisms used to protect enterprise network credentials are insufficient. IT
security architects face several challenges with existing security solutions.
These challenges help tip the scales in favour of the attackers:
• Security Information & Event Management (SIEM) solutions rely on blacklisting and require overworked
analysts to sift through noisy notifications
• Software patching cycles inevitably lag vulnerability exploit release, sometimes by months or years
• Traditional antivirus cannot detect firmware and boot level attacks
• Passwords are always too weak
• User multifactor authentication solutions are too expensive
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-27
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
Credential theft (3 of 3)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Credential theft attack requires the understanding (cont.) of the following:
– Protection from credential theft
© Copyright IBM Corporation 2016
Figure 3-16. Credential theft (3 of 3)
Notes:
Protection from credential theft
Credential theft can be mitigated by using the hardware root of trust combined with defence in depth.
Packaging the raw materials of effective credential protection has, until now, been the exclusive domain of
advanced government research. In order to protect from credential theft, you as a user must not write down
personal identity security information in any form either digital or paper based. You should never provide your
personal information to anybody via phone or email if you did not call the concerned department for support.
Also, analyse what you are sharing in your social media; if something sensitive is present do not hesitate to
delete the information in order to protect yourself from identity theft and fraud.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-28
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
Elevation of privilege
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Elevation of privilege attack requires the understanding of the following:
– Basics of elevation of privilege
© Copyright IBM Corporation 2016
Figure 3-17. Elevation of privilege
Notes:
Basics of elevation of privilege
Elevation of privilege results from giving an attacker authorization permission beyond those initially granted.
For example, an attacker with a privilege set of "read only" permissions somehow elevates the set to include
"read and write." Exceeding normal access privileges to gain administrative rights or access to confidential
files. Common cause includes running web server processes as root or administrator, using coding errors to
allow buffer overflows, and elevate application into a debug state. Preventive measures include using
fewest-privileges context whenever possible, using type-safe languages and compiler options to prevent or
control buffer overflows.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-29
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
Basics of authorisation (1 of 3)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Authorization attack requires the understanding of the following:
– Basics of authorization
– Disclosure of confidential data
© Copyright IBM Corporation 2016
Figure 3-18. Basics of authorisation (1 of 3)
Notes:
Basics of authorization
Authorization specify all IDs and resources that each can access, identify privileged resources and privileged
operations, separate privileges for different roles that is built in authorization granularity, and identify
code-access security requirements. Countermeasure is to restrict database logins to access-specific stored
procedures; do not allow direct access to tables; and restrict access to system-level resources.
Disclosure of confidential data
Confidential information may be disclosed when discussing business proposals with clients, using employees
to carry out work, engaging third party contractors and communicating business information to suppliers. This
disclosure may take place face-to-face, over the telephone, by fax, by email or over the internet. Again, you
should consider the method of disclosure and assess what measures you can take to ensure the information
remains confidential. One way of maintaining the secrecy of information is by imposing specific confidentiality
obligations on its intended recipients.
These obligations can be set out in confidentiality letters/agreements and notices (on documents, faxes,
emails, etc.). It is crucial that you impose these obligations before disclosing the confidential information.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-30
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
Basics of authorisation (2 of 3)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Authorization attack requires the understanding (cont.) of the following:
– Example of disclosure of confidential data
– The conclusion of a Non-disclosure Agreement (NDA)
© Copyright IBM Corporation 2016
Figure 3-19. Basics of authorisation (2 of 3)
Notes:
Example of disclosure of confidential data
In a corporate scenario, a legal due diligence review of the target company is performed using standard
procedure. During the course of the review, confidential information about the target company itself and its
business relations is disclosed to the purchaser. In order to cater for the interests of both seller and
purchaser, the parties generally enter into a non-disclosure agreement (NDA).
During the course of a legal due diligence review, various individuals have access to highly sensitive
corporate data. During the disclosure of such confidential information, confidentiality obligations under which
both the management of the target company as well as the selling shareholders operate could be violated.
These obligations could derive from the law or be stipulated by contract, for example in contracts entered into
between the target company and suppliers or clients. The disclosure of confidential information during a due
diligence review can be managed in different ways depending on the intended transaction structure, so as to
do justice to both the potential purchaser’s interest in information as well as the confidentiality obligations of
the potential seller.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-31
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
The conclusion of a Non-Disclosure Agreement (NDA)
At the very beginning of a contemplated transaction, parties enter into a NDA. In many cases, the conclusion
of a NDA is necessary in order to enable the management of the target company to disclose any confidential
information without violating their confidentiality obligations in the first place. In the NDA, the disclosing party
and the recipients of the information of the potential purchaser should be named. In addition, the agreement
should contain a ban from using the findings for own or third party purposes, as well as a non-solicitation
clause as regards staff, clients and suppliers.
Furthermore, the obligations under the NDA should be secured by way of contract penalty. Finally, it should
be ensured that the transferor of the confidential information has control over the detailed procedure
concerning the inspection of relevant documents. This can be done by determining different access rights in
relation to specific individual documents in the data room for example determining whether or not the
potential purchaser is free to save or print certain documents or if the documents can only be seen on the
screen.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-32
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
Basics of authorisation (3 of 3)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Authorization attack requires the understanding (cont.) of the following:
– Creating anonymised contract summaries
– Setting up a black box data room
– The timely involvement of legal advisors
© Copyright IBM Corporation 2016
Figure 3-20. Basics of authorisation (3 of 3)
Notes:
Creating anonymised contract summaries: The most extensive protection of confidential information
combined with the lowest risk of violating confidentiality obligations is provided by setting up a so-called black
box data room in which the confidential information on the target company is placed. Only advisors of
potential purchasers who are bound by professional confidentiality obligations have access to this data room.
They can view the information and are only allowed to disclose certain results to the potential purchaser. The
setting up of a black box data room is especially appropriate for controlled or open bidding processes during
which various potential purchasers are supposed to get access to confidential information about the target
company.
Setting up a black box data room: In order to recognize and manage the elaborate array of problems that
result from the publication of confidential information within the context of an M&A transaction, it is advisable
to involve a legal advisor as early as possible. This will allow parties sufficient time to implement appropriate
measures for the protection of the target company’s management, for example by approving board
resolutions or shareholders’ resolutions on the disclosure of sensitive information to the potential purchaser.
The timely involvement of legal advisors: In order to recognize and manage the elaborate array of
problems that result from the publication of confidential information within the context of an M&A transaction,
it is advisable to involve a legal advisor as early as possible. This will allow parties sufficient time to
implement appropriate measures for the protection of the target company’s management, for example by
approving board resolutions or shareholders’ resolutions on the disclosure of sensitive information to the
potential purchaser.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-33
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
Data tampering
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Data tampering attack requires the understanding of the following:
– Basics of data tampering
– Detailed description of data tampering
© Copyright IBM Corporation 2016
Figure 3-21. Data tampering
Notes:
Basics of data tampering: Data tampering is the intentional manipulation and destruction of data, which
may or may not be discovered until sometime in the future. Data can be tampered either in the stored or in
the transit stage. Unprotected data packets can be wiretapped or altered and can be corrupted due to the
execution of malevolent codes provided by the attacker. Apart from controlling access to web application, the
hashes and digital signature should also be used in data encryption. Also, in data transmission end to end
protocols like Secure Socket Layer (SSL) / Transport Layer Security (TLS) should be used.
Detailed description of data tampering: Data tampering holistically mean changing or deleting a resource
without authorization, for example defacing a website or altering data in transit. Common causes of data
tampering include trusting data sources without validation, sanitizing input to prevent execution of unwanted
code, running with escalated privileges, and leaving sensitive data unencrypted. In order to prevent data from
being tampered, use operating system security to lock down files, directories, and other resources; validate
your data, and use hash and sign data in transit such as SSL or IPsec.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-34
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
Luring attack
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Luring attack requires the understanding of the following:
– Basics of luring attack
© Copyright IBM Corporation 2016
Figure 3-22. Luring attack
Notes:
Basics of luring attack
Luring attack is a type of elevation-of-privilege attack in which an attacker lures a highly privileged component
to do something on his behalf. The most straightforward way of doing this is to persuade the target to run
attackers code in more privileged security context. In this type of attack trusted code is unknowingly
conducted to make a call into an attacker’s code fragments. The risk with this script seems to stem from the
implied guess that the called routine acquires the authority of its caller.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-35
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
Phishing attack
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Phishing attack requires the understanding of the following:
– Basics of phishing attack
© Copyright IBM Corporation 2016
Figure 3-23. Phishing attack
Notes:
Basics of phishing attack
Banking and e-commerce sites are mostly effected by the phishing attacks. In this attack the attacker tries to
steal the personal data, credit card details, and credentials by masquerading the reliable identity. To reduce
the risk of phishing the application developer can follow few precautions. In most of the scams there is
misrepresentation and the victim is clearly identifiable, but phishing is totally a different case.
• The victim is one whose identity is stolen. And the person will be repeatedly victimized for years. Simply
draining their bank account is not the end. Like all types of identity theft, the damage is never completely
resolved. Just when the person thinks that everything has finally been cleaned up, the information is used
again.
• Banks, ISPs, stores, and other phishing targets are victimized – they suffer a huge loss of reputation and
trust by consumers. If you have received a legitimate email from Citibank today, would you trust it?
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-36
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
Checkpoint
IBM ICE (Innovation Centre for Education)
IBM Power Systems
1.
Which of the following is method of authentication?
A.
B.
C.
D.
2.
Which of the following is Authentication methods?
A.
B.
C.
D.
3.
Password
Smart card
Biometric
All of the above
Kerberos
PAP
CHAP
SSL
Which of the following is not an authentication vulnerability?
A.
B.
C.
D.
Eavesdropping
Brute force attack
Dictionary attack
All of the above
© Copyright IBM Corporation 2016
Figure 3-24. Checkpoint
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-37
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
Checkpoint
IBM ICE (Innovation Centre for Education)
IBM Power Systems
4.
Which of the following attack can be operated by sending an email?
A.
B.
C.
D.
5.
Controls must be established in a system in order to
A.
B.
C.
D.
6.
Phishing
Luring
Both of the above
None of the above
Prohibit tampering with information by unauthorized person
Verify that all data have been processed
The concurrent operation of an existing system and a new system
All of the above
What could lead to a potential disclosure of confidential data?
A.
B.
C.
D.
Signing a Non-Disclosure Agreement
Sending confidential information via secured channels to a person
Do not store confidential information where it is easily accessible by unauthorised persons.
None of the above
© Copyright IBM Corporation 2016
Figure 3-25. Checkpoint
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-38
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
Checkpoint
IBM ICE (Innovation Centre for Education)
IBM Power Systems
7.
Principle of least privilege means
A.
B.
C.
D.
8.
While disclosing confidential information one should
A.
B.
C.
D.
9.
Limited privilege to do their jobs
Security is paramount privileges should be provided to trusted people
Everyone should have similar least possible privileges
None of the above
Take due permission form the organisation
Not disclose it completely
Always share the confidential information by email of approves secure channel
None of the above
When to use a NDA?
A.
B.
C.
D.
On the joining of an employee
While sharing a confidential information with third party vendors
Before entering into any kind of professional engagement
All of the above
10. Eavesdropping is kind of
A.
B.
C.
D.
Malware
Man in the middle attack
SQL vulnerability
Encryption method
© Copyright IBM Corporation 2016
Figure 3-26. Checkpoint
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-39
V11.0
Unit 3. Introduction to authentication & authorization
Uempty
Unit summary
IBM ICE (Innovation Centre for Education)
IBM Power Systems
After completing this unit, you should be able to:
• Get an overview of authentication process
• Understand the importance of authorization
© Copyright IBM Corporation 2016
Figure 3-27. Unit summary
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
3-40
V11.0
Unit 4. Introduction to configuration management & session management
Uempty
Unit 4. Introduction to configuration
management & session
management
Overview
This unit provides an insight on configuration management and session management.
How you will check your progress
• Checkpoint
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
4-1
V11.0
Unit 4. Introduction to configuration management & session management
Uempty
Unit objectives
IBM ICE (Innovation Centre for Education)
IBM Power Systems
After completing this unit, you should be able to:
• Gain insight on configuration management
• Understand the basics of session management
© Copyright IBM Corporation 2016
Figure 4-1. Unit objectives
Notes:
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
4-2
V11.0
Unit 4. Introduction to configuration management & session management
Uempty
Introduction to configuration management &
session management (1 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Configuration management requires the understanding of the following:
– Basics of configuration management
© Copyright IBM Corporation 2016
Figure 4-2. Introduction to configuration management & session management (1 of 2)
Notes:
Introduction to configuration management & session management
Configuration management protect administration interfaces and remote administration channels with strong
authentication and authorization capabilities, provide role-based administrator privileges, and use
least-privileged process and service accounts. Construct secure configuration stores and do not hold
confidential data in plain text configuration files. For session management, limit the session lifetime, protect
the session state from unauthorized access, and ensure that session identifiers are not passed in query
strings.
Basics of configuration management
Configuration management is about managing the parts of software or services work together in well manner,
even a simple application likely needs some configuration like providing database credentials or a web
service endpoint. Many applications hold configuration management interfaces and functionality to enable
users to make some changes in configuration parameter, to upgrade web site content, and to perform in good
manner.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
4-3
V11.0
Unit 4. Introduction to configuration management & session management
Uempty
Introduction to configuration management &
session management (2 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Configuration management requires the understanding (cont.) of the following:
– Configuration management vulnerability
– Protection from configuration management issues
– Requirements of configuration management
© Copyright IBM Corporation 2016
Figure 4-3. Introduction to configuration management & session management (2 of 2)
Notes:
Configuration management vulnerability
• Unauthorized access to administration interfaces
• Unauthorized access to configuration stores
• Recovery of plaintext configuration mysteries
• Absence of individual responsibility
• Over-privileged process and service accounts
Protection from configuration management issues
Insure that a verified application consists of:
• Up to date collections and stage(s).
• A secure by default configuration.
• Necessary hardening when user want to changes to default configuration it should not disclose or
produce security flaws
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
4-4
V11.0
Unit 4. Introduction to configuration management & session management
Uempty
Requirements of configuration management
1. All components should be up to date with proper security configurations and latest versions. It contains
removal of unwanted configurations and files like platform documentation, sample applications, and
default users.
2. When components are in different system there should be encrypted communication between the
database server and application server.
3. Communication should be authenticated between components using an account with minimum required
rights.
4. Verify that distribution process and application build be performed in secure manner
5. Verify that all application components are signed.
6. Verify that third party components come from trusted repositories.
7. Ensure that build processes for system level languages have all security flags enabled, such as ASLR,
DEP, and security checks.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
4-5
V11.0
Unit 4. Introduction to configuration management & session management
Uempty
Unauthorized access to administration
interfaces (1 of 3)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Configuration management requires the understanding of the following:
– Basics of unauthorized access to administration interfaces
© Copyright IBM Corporation 2016
Figure 4-4. Unauthorized access to administration interfaces (1 of 3)
Notes:
Basics of unauthorized access to administration interfaces
Administration connections enables controlling persons, operators, and content designers to handle site
content and configuration and often provided by added web pages and separate web applications. It should
be like only authorized and limited users can access the administration connections. Bad users can take the
application out of action completely by having errors or changes in configuration details, can possibly deface
the net places, access the current systems and knowledge-bases, if they get to access the configuration
management work. Unauthorized access can be stopped by following the steps:
• Making small number of organization connections.
• Using strong checking to make certain, for example, by document attesting to the truth of certain stated
facts (certificates)
• Use strong authority with many gatekeepers.
• In case of supporting always try to prefer only local or nearby administration. Use encrypted channels, for
example technology or SSL, if remote administration is completely essential. Because of the nature of
the data passed over administrative connections is sensitive. Use IPsec policies to limit remote
administrative to computers on the inside network, to further cut down danger.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
4-6
V11.0
Unit 4. Introduction to configuration management & session management
Uempty
Attackers whose goal is to gain administrator privilege on a Target application computer Administrative
Interfaces access will be the last end goal for them. They use systematic plan of attacking including SQL
injection, cross-site rough writing, parameter tampering, and so on. Once they able to access administrative
Interfaces, they can take total control all applications and possibly other parts of the network and can also
implant backdoors for making way in the applications for future use.
If Unauthorized attacker access the administrator settings, he can modify them accordingly to the type of
privileges needed to the system. In this sort of attack, the attacker feats different feebleness’s in net
connections of cloud givers using which the services are provided to the users.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
4-7
V11.0
Unit 4. Introduction to configuration management & session management
Uempty
Unauthorized access to administration
interfaces (2 of 3)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Configuration management requires the understanding (cont.) of the following:
– Detailed description of unauthorized access to administration interfaces
© Copyright IBM Corporation 2016
Figure 4-5. Unauthorized access to administration interfaces (2 of 3)
Notes:
Detailed description of unauthorized access to administration interfaces
Remote administration flaws are the most ignored, but important category of application safety vulnerabilities.
Many product designers, including security product, blindly trust the nature of environment in which they
operate to maintain security. They do not set the password or security codes to protect application interfaces
because they think, only authorized system or user can access the administrative interfaces. Because of
unawareness, Administrators allow the remote access to administrative interfaces on internet. The
administrative interface when accessed by HTTP, does not limit failed permit efforts. It is only a matter of time
until the right controlling person's password is discovered, when attacker directly employs a strong force on
password area. When settled the attacker can take the total control of applications and head to compromise
of the total network. A compromised network can also be used to implant the backdoors in system or
application allowing the attacker to gain privileged access to the system even after the connection feebleness
has been adjusted.
An attacker can use the various ways of attacks like cross-site scripting, SQL injection, buffer overflow,
parameter tampering and many others. Access to administrative interface is blocked to prevent the
unauthorised access. Unauthorized Web pages are accessed by attackers and Prevention Systems and
Intrusion Detection are not Web application oriented so it cannot state which web page is authorised and
which is not, that’s why these products take all pages similar.
Product must have some knowledge to know which page is authorized and which one is not, and to gain this
knowledge there are two ways. You can either configure the product with the name of the allowed pages or
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
4-8
V11.0
Unit 4. Introduction to configuration management & session management
Uempty
the product can learn that automatically from the network traffic. The product learns which pages are allowed
to be accessed During learn mode. You can also manually configure the product with that information. During
protect mode the product will alert for any attempt to access unauthorized pages from the Internet.
Administrator interfaces may be present in the application or on the application server to allow certain users
to undertake privileged activities on the site. Tests should be undertaken to reveal if and how this privileged
functionality can be accessed by an unauthorized or standard user.
An application may require an administrator interface to enable a privileged user to access functionality that
may make changes to how the site functions. Such changes may include:
• user account provisioning
• site design and layout
• data manipulation
• configuration changes
In many instances, such interfaces do not have sufficient controls to protect them from unauthorized access.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
4-9
V11.0
Unit 4. Introduction to configuration management & session management
Uempty
Unauthorized access to administration
interfaces (3 of 3)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Configuration management requires the understanding (cont.) of the following:
– Black box testing
– Grey box testing
© Copyright IBM Corporation 2016
Figure 4-6. Unauthorized access to administration interfaces (3 of 3)
Notes:
Black box testing
The following section describes vectors that may be used to test for the presence of administrative interfaces.
These techniques may also be used to test for related issues including privilege escalation.
• Comments and links in source code. Many sites use common code that is loaded for all site users. By
examining all source sent to the client, links to administrator functionality may be discovered and should
be investigated.
• Reviewing server and application documentation. If the application server or application is deployed in its
default configuration it may be possible to access the administration interface using information
described in configuration or help documentation. Default password lists should be consulted if an
administrative interface is found and credentials are required.
• Publicly available information. Many applications such as WordPress have default administrative
interfaces.
• Alternative server port. Administration interfaces may be seen on a different port on the host than the
main application. For example, Apache Tomcat's Administration interface can often be seen on port
8080.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
4-10
V11.0
Unit 4. Introduction to configuration management & session management
Uempty
• Parameter tampering. A GET or POST parameter or a cookie variable may be required to enable the
administrator functionality. Clues to this include the presence of hidden fields such as: <input
type="hidden" name="admin" value="no"> or in a cookie: Cookie: session_cookie; useradmin=0
Once an administrative interface has been discovered, a combination of the above techniques may be used
to attempt to bypass authentication. If this fails, the tester may wish to attempt a brute force attack. In such an
instance the tester should be aware of the potential for administrative account lockout if such functionality is
present.
Grey box testing
A more detailed examination of the server and application components should be undertaken to ensure
hardening that is administrator pages are not accessible to everyone through the use of IP filtering or other
controls, and where applicable, verification that all components do not use default credentials or
configurations. Source code should be reviewed to ensure that the authorization and authentication model
ensures clear separation of duties between normal users and site administrators.
User interface functions shared between normal and administrator users should be reviewed to ensure clear
separation between the drawing of such components and information leakage from such shared functionality.
Administrator interfaces may be present in the application or on the application server to allow certain users
to undertake privileged activities on the site. Tests should be undertaken to reveal if and how this privileged
functionality can be accessed by an unauthorized or standard user. An application may require an
administrator interface to enable a privileged user to access functionality that may make changes to how the
site functions. Such changes may include:
• user account provisioning
• site design and layout
• data manipulation
• configuration changes
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
4-11
V11.0
Unit 4. Introduction to configuration management & session management
Uempty
Unauthorized access to configuration
stores
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Unauthorized access to configuration stores requires the understanding of the following:
– Basics of unauthorized access to configuration stores
– Protection of configuration stores
– Retrieval of plaintext configuration secrets
© Copyright IBM Corporation 2016
Figure 4-7. Unauthorized access to configuration stores
Notes:
Unauthorized access to configuration stores
Basics of Unauthorized Access to Configuration Stores
This kind of unauthorized access makes an attacker able to make changes to sensitive configuration files and
along with holding the settings of system. This is an attack on unity and privacy of configuration files due to
either improper access control mechanism or failure of access control operations. The system and
configuration files of the cloud services at the SaaS, PaaS or IaaS layer are main target of such attacks.
Mostly data of configuration stores, is of sensitive type so you should make sure all data stores are protected.
Protection of configuration stores
• Arrange limited ALSs on text based configuration files such as Machine.config and Web.config.
• Keeping custom configuration stores separate from web space removes the possibility to download Web
server configurations to feat their vulnerabilities.
Retrieval of plaintext configuration secrets
It is must to limit the access to configuration store. You should encrypt sensitive data like password and
connection series. It will help to stop attackers from getting configuration data and also prevent unreliable
administrations and employees in organization from getting sensitive details about database series and
authorisations with the help of which they can access to other systems.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
4-12
V11.0
Unit 4. Introduction to configuration management & session management
Uempty
Retrieval of clear text configuration data
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Retrieval of clear text configuration data requires the understanding of the following:
– Basics of retrieval of clear text configuration data
© Copyright IBM Corporation 2016
Figure 4-8. Retrieval of clear text configuration data
Notes:
Basics of retrieval of clear text configuration data
Anyone who can log in to the server can see your secret data if you store it in clear texts. If you pass sensitive
data in clear texts over networks, Eavesdroppers can reveal or temper with your sensitive data by monitoring
the network. Analyse how encrypted data is stored in application stores. Check that application does not
store your secret data in clear texts. For extreme security, access to the encrypted data should be restricted
with Window ACLs. Check that how application accesses the secrets and how long they are kept in memory
in clear wordings. In general, Secrets should be retrieved only on request, used for the minimum period of
time, and then rejected. Be certain the application does give sensitive data in question strings because these
are registered and are also clearly able to be seen in the client s browser address bar. Avoid Plaintext
Passwords in Configuration Files The <processModel>, <sessionState>, and <identity> elements in
Machine.config and Web.config have userName and password attributes.
These should not be stored in clear texts. Use Aspnet_setreg.exe tool to store encrypted authorizations and
identifications in the registry. Programmers need to be having knowledge of what data is stored in session
objects, depending on where the session objects are stored (DB, file-system, RAM, etc.) different rules may
be capable of being applied.
For example, the application may fail to PCI DSS standards for storing PAN (primary account number) in
clear wording if session objects are assembled to be stored in the file system on the first server and credit
card numbers are stored in session objects. As far as the programmers are concerned, without realizing that
the data is ending up on the file system they are just storing the data in a session object. In such type of
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
4-13
V11.0
Unit 4. Introduction to configuration management & session management
Uempty
situations, you may need to consider encrypting the data that is being stored in the session object. If it is must
to store the secrets, then do not store in clear wordings in source code or in configuration files. Passing
sensitive data and credentials in clear text over unencrypted communication channels can let an attacker to
guide the network to get credentials and possibly tamper with other sensitive data items.
Detect application menaces and recognise key vulnerabilities like Storing configuration secrets, such as
connection strings and service account credentials, in clear text. Clear text credentials in configuration files:
Insiders who can access the server or attackers who exploit a host vulnerability to download the configuration
file have immediate access to credentials. Passing clear text credentials over the network: Attackers can
guide the network to steal authentication credentials and spoof identity. To protect the credentials during
transfer use SSL and never pass credentials in clear texts over the wire. Database connection strings
become vulnerable if it is hard coded or stored in clear text in configuration files or the COM+ catalogue.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
4-14
V11.0
Unit 4. Introduction to configuration management & session management
Uempty
Lack of individual accountability
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Lack of individual accountability requires the understanding of the following:
– Basics of lack of individual accountability
© Copyright IBM Corporation 2016
Figure 4-9. Lack of individual accountability
Notes:
Basics of lack of individual accountability
Application server assign the session-ids which are random identifiers to individually identify and classify
operators. They should not be used such as cryptographic keys or to produce distinctive file names. Sessionids can be visible if they are used for other purposes. Session-ids should not be re-assigned to another
person after a user log out to stop replay attacks. Absence of auditing and logging of changes made in
configuration information intimidate the ability to find who made those changes and when changes were
made. When a breaking change is made either by attacker or by an honest operator error to grant
confidential access, action must first be taken to correct the change. Then apply preventive measures to
prevent breaking changes to be introduced in the same manner.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
4-15
V11.0
Unit 4. Introduction to configuration management & session management
Uempty
Over-privileged process and service
accounts
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Over-privileged process and service accounts requires the understanding of the following:
– Basics of 0ver-privileged process and service accounts
© Copyright IBM Corporation 2016
Figure 4-10. Over-privileged process and service accounts
Notes:
Basics of over-privileged process and service accounts
If service accounts and applications are allowed to make changes in configuration information on the system,
they may be got control of to do so by an attacker. By accepting a policy of using application accounts and
minimum privileged service, the risk of this threat can be diminished. Be careful of giving accounts the
authority to change their own configuration information unless explicitly needed by design. Session-ids
should be renewed every time, the user’s privilege changes and user moves from HTTP to HTTPS and vice
versa.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
4-16
V11.0
Unit 4. Introduction to configuration management & session management
Uempty
Basics of Session Management (1 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Session management requires the understanding of the following:
– Basics of session management
– Control objectives of session management
© Copyright IBM Corporation 2016
Figure 4-11. Basics of Session Management (1 of 2)
Notes:
Basics of session management
Session management is an application layer responsibility for the Web applications and to the overall security
of the application, session security is the most critical part. Top session management menaces include
session hijacking, session replay, and man in the middle. A session id should be complex, lengthy, having
unpredictable random numbers. It should be changed regularly throughout a session to minimise the time
period a session ID remains valid. Moreover, a session ID should not be stored in hidden HTML fields or
HTTP headers, persistent cookies and URL. Programmers can consider storing session IDs in a client
browser’s session cookies. Session IDs can be secured from being sniffed by attackers, by employing SSL or
TLS. An idle session timeout and logout function should also be implemented for the application. Both the
server side cookie and client side cookie should be cleaned up after timing-out an idle session and logging off
a user.
Control objective of session management
The mechanism by which web based application controls and maintains the state for a user interacting with it
is one of the main elements of any web based application. This is related to session management and is
defined as the set of all controls or countermeasures governing state-full interaction between a user and the
web-based application. Make sure that a verified application satisfied the following session management
requirements: for each individual, session is distinct and cannot be shared or guessed; and sessions are
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
4-17
V11.0
Unit 4. Introduction to configuration management & session management
Uempty
cancelled when there is no longer needed and timed out during periods of inactivity. Need to verify the
followings:
1. There is no custom session manager, and custom session manager should be strongly against all
common session management attacks
2. Sessions are cancelled when the user logs out
3. Sessions timeout after a specified time of inactivity
4. Sessions timeout after an administratively-configurable maximum time period regardless of activity
5. All pages that need authentication have simple and visible access to logout functionality
6. The session id is never disclosed in URLs, error messages, or logs
7. All successful authentication and re-authentication generates a new session and session-id
8. Only session ids created by the application are recognized as active by the application
9. Session ids are random, unique and sufficiently long across the correct active session base
10. The application limits the number of active concurrent session
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
4-18
V11.0
Unit 4. Introduction to configuration management & session management
Uempty
Basics of Session Management (2 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Session management requires the understanding (cont.) of the following:
– Broken authentication and session management vulnerability
– Protection from broken authentication and session management
© Copyright IBM Corporation 2016
Figure 4-12. Basics of Session Management (2 of 2)
Notes:
Broken authentication and session management vulnerability
Are session IDs and user credentials properly protected? You may be open to attack if:
1. User authentication credentials aren’t secure when stored using hashing or encryption
2. Credentials can be guessed or overwritten through weak account management functions for example
weak session IDs, change password, account creation, recover password
3. Session IDs are visible in the URL for example in URL rewriting
4. Session IDs are vulnerable to session fixation attacks
5. Session IDs don’t timeout, or user sessions or authentication tokens, particularly single sign-on (SSO)
tokens, aren’t properly invalidated during logout
6. Session IDs aren’t rotated after successful login
7. Session IDs, passwords, and other credentials are sent over unencrypted connections
Protection from broken authentication and session management
Ensure that you completely avoid XSS vulnerability that can thieve session IDs.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
4-19
V11.0
Unit 4. Introduction to configuration management & session management
Uempty
Hijacking attack
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Hijacking attack requires the understanding of the following:
– Basics of hijacking
– Protection from session hijacking
© Copyright IBM Corporation 2016
Figure 4-13. Hijacking attack
Notes:
Basics of hijacking attack
When an attacker uses network monitoring software to catch the authentication token (often a cookie) used to
represent a user's session with an application is called session hijacking. The attacker can take-off the user's
session and get access to the application, with the help of captured cookie. The attacker has the same rights
as the real operator.
Protection from session hijacking attack
The methods that can be employed to protect against session hijacking include creation of a secure
communication channel via SSL, passing the authentication cookie over an HTTPS connection, allowing a
user to close a session, enforce logout functionality that forces verification if a new session is started. If you
do not use SSL, then make sure you limit the ending period on the session cookie, as it decreases the time
window available to the hacker. It is easier to sneak in to a system as a genuine user than to attempt to enter
a system directly. A hacker can enter a genuine session by finding an established session and taking it over
after the user has been authenticated. Once the session has been hijacked, the attacker can stay connected
for hours without arousing suspicion. All routed traffic destined for the user’s IP address comes to the
attacker’s system. During this time, the attacker can plant backdoors or even gain additional access to a
system. The hijack can be broken down into three broad phases which have been depicted in the figure.
The detailed description of the steps are as follows:
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
4-20
V11.0
Unit 4. Introduction to configuration management & session management
Uempty
• Tracking the Connection: The attacker uses a network sniffer to track a victim and host or uses a tool
like Nmap to scan the network for a target with a TCP sequence that is easy to predict. Once the victim is
identified, the attacker captures sequence and acknowledgment numbers from the victim. Because
packets are checked by TCP through sequence and/or acknowledgment numbers, the attacker uses
these numbers to construct packets.
• Desynchronizing the Connection: When there is an established or a stable connection with no data
transmission between the host and the target then this state is called desynchronized state. When the
sequence number of the client is not equal to the acknowledgement number of the server or vice-versa,
then also the state is called desynchronized state. The sequence or the acknowledgement number of the
server must be charged by the attacker in order to desynchronize the connection between the host and
the target. To achieve this state, null data is sent by the attacker to the server in order to advance the
sequence number or the acknowledgment number of the server. This happens without the knowledge of
the machine which has been targeted as it does not register any augmentation. For example: Before
de-synchronization, the attacker monitors the session without any kind of interference. The attacker then
sends a large amount of null data to the server. These data change the ACK number on the server but do
not affect anything else. Thus, both the target and the server are desynchronized. The connection
available on the server site can also be brought down by sending a reset flag to the server. When the
setup is in its early stage, then only this occurs. There are mainly two goals of an attacker. First is
breaking the connection on the side of the server and second is creating a different connection with the
various sequence numbers. A SYN or an ACK packet is listened by the attacker which has been sent by
the server for the host. A RST packet in sent immediately by the attacker when the packet is detected.
Also a SYN packet is sent by the attacker which is of the same parameter as of the RST packet. Based
on the SYN packet, the connection is closed and another one is initiated. The sequence number of the
SYN packet is different than the RST packet. A new connection is then established and SYN or ACK
packet is sent to the target for acknowledging it. After the RST packet is received by the server, it closes
the connection with the targeted system and another connection is initiated which is based on the SYN
packet. The packet is sent on the same port but the sequence number of the packet is different. Now, the
target is sent a SYN or ACK packet acknowledgement. An ACK packet is then sent by the attacker after a
new connection is detected. This state of the server is known as an established state. To keep the target
conversant is the main aim of this state. When the first SYN or ACK packet is received from the server,
then it must switch to establishment state. Now established but desynchronized state is achieved on both
the target and the server. FIN flag can also be used to do this, but the attack will be given away in this
way as the server will respond with an ACK. This response from the server is also known as ACK storm.
This method of hijacking has a flaw embedded in it which causes the ACK storm to take place. Now, both
target and server are established but are in a desynchronized state. A FIN flag can be used to do this.
Now the server will respond to this ongoing process by generating a ACK and will give away the attack by
using an ACK storm. There is a flaw in the method of TCP connection hijacking which makes this to take
place. The sequence number which is expected is sent by the host in order to ACK the packet which has
been received. An acknowledgement packet will now be generated after receiving an unacceptable
packet which will create a loop of endless nature for every data packet available. An access of traffic
associate with the network will be resultant by the mismatch in ACK and SEQ numbers in the target and
the server which will try to verify the correct sequence. No data is carried by these packets; thus they are
not transmitted again if in case the packet is lost. The conversion between the target and the server
which is unwanted can be put to hand by a single loss of packet. This happens because IP is used by
TCP in this process. In order to make sure the target host has no knowledge about the attack, the stage
of desynchronization is added to the sequence of hijacking. An attacker is able to inject data to the server
without desynchronization. The attacker can even keep the identity by carrying out a IP address spoof.
• To Inject the Packet of the Attacker: After the connection between the server and the target has been
interrupted by the attacker, data can be injected by the attacker into the network or data can be passed
from the targeted system to the malicious server by participating actively as the man in the middle. Data
can also be read and injected freely.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
4-21
V11.0
Unit 4. Introduction to configuration management & session management
Uempty
Session replay attack
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Session replay attack requires the understanding of the following:
– Basics of session replay attack
© Copyright IBM Corporation 2016
Figure 4-14. Session replay attack
Notes:
Basics of session replay attack
Session replay attack is used by an attacker to avoid the authentication process. Attacker captures and
submits the user’s session token known as session replay. For example, if session token is left in cookie or
URL an attacker can easily steal it and can post a request using the hijacked session token. In order to stop
the session replay there should be re-authentication while performing critical tasks for example in case of
money transfer make user to conform the password again, expire session properly including all session token
and cookies, and create ‘a do not remember me’ option to allow no session data to be stored on the client.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
4-22
V11.0
Unit 4. Introduction to configuration management & session management
Uempty
Man in the middle attack
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Man in the middle attack requires the understanding of the following:
– Basics of man in the middle attack
© Copyright IBM Corporation 2016
Figure 4-15. Man in the middle attack
Notes:
Basics of man in the middle attack
Man in middle attack take place when an attacker interrupts communications between you and your receiver.
The attacker read your massage, after changing it he sends it to receiver, then receiver receives your
massage, sees that it came from you and reply on it. when receiver sends a massage back to you the
attacker interrupts it, alters it, and returns it to you. You and your receiver never know that you have been
attacked. Any network request including client-server communication, including Web requests, Distributed
Component Object Model (DCOM) requests, and calls to remote components and Web services, are subject
to man in the middle attacks. In order to prevent man in the middle attacks, always use cryptography before
transmitting the data since if you encrypt the data attacker can interrupt it but cannot read it or change it. Use
Hashed Message Authentication Codes (HMACs). If an attacker changes the message, the recalculation of
the HMAC at the receiver end fails and the data can be rejected as invalid.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
4-23
V11.0
Unit 4. Introduction to configuration management & session management
Uempty
Checkpoint
IBM ICE (Innovation Centre for Education)
IBM Power Systems
1. Which of the following is not a configuration management threat?
A.
B.
C.
D.
Unauthorized access to administration interfaces
Unauthorized access to configuration stores
Lack of individual accountability
Under-privileged process and service accounts
2. Full form of DCOM:
A.
B.
C.
D.
Distributed Component Object Model
Directory Component Object Model
Direct Computer Oriented Method
Distributed Computer Object Model
© Copyright IBM Corporation 2016
Figure 4-16. Checkpoint
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
4-24
V11.0
Unit 4. Introduction to configuration management & session management
Uempty
Checkpoint
IBM ICE (Innovation Centre for Education)
IBM Power Systems
3. HMACs stands for?
A.
B.
C.
D.
High Media Access Controls
Hashed Minute Authentication Codecs
Hashed Message Authentication Codes
Hashed Message Authorization Codes
4. A session ID should be:
A.
B.
C.
D.
Complex
Lengthy
Unpredictable random numbers
All of the above
© Copyright IBM Corporation 2016
Figure 4-17. Checkpoint
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
4-25
V11.0
Unit 4. Introduction to configuration management & session management
Uempty
Checkpoint
IBM ICE (Innovation Centre for Education)
IBM Power Systems
5. A session ID should not be stored in?
A.
B.
C.
D.
Hidden HTML fields and HTTP headers
Persistent Cookies and URLs
Both A and B
Neither A nor B
6. Applications should not store secret data in:
A.
B.
C.
D.
Clear Text
Cypher Text
Enciphered Text
Coded Text
© Copyright IBM Corporation 2016
Figure 4-18. Checkpoint
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
4-26
V11.0
Unit 4. Introduction to configuration management & session management
Uempty
Checkpoint
IBM ICE (Innovation Centre for Education)
IBM Power Systems
7. Which of the following testing mechanism is used in administrator interfaces?
A.
B.
C.
D.
Green box testing
Blue box testing
Both A and B
Neither A nor B
8. By avoiding XSS vulnerability you can protect your web application from broken authentication and
session management.
A. True
B. False
© Copyright IBM Corporation 2016
Figure 4-19. Checkpoint
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
4-27
V11.0
Unit 4. Introduction to configuration management & session management
Uempty
Checkpoint
IBM ICE (Innovation Centre for Education)
IBM Power Systems
9. __________ is used to compare the true value and the arrived value in order to validate the nontampering of the data
A.
B.
C.
D.
HMACs
MACs
XML
Matching
10. A perpetrator can steal your session through?
A.
B.
C.
D.
Hijacking
Session Replay Attack
Both A and B
Neither A nor B
© Copyright IBM Corporation 2016
Figure 4-20. Checkpoint
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
4-28
V11.0
Unit 4. Introduction to configuration management & session management
Uempty
Unit summary
IBM ICE (Innovation Centre for Education)
IBM Power Systems
After completing this unit, you should be able to:
• Gain insight on configuration management
• Understand the basics of session management
© Copyright IBM Corporation 2016
Figure 4-21. Unit summary
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
4-29
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
Unit 5. Introduction to cryptography,
parameter manipulation &
exception management
Overview
This unit provides an insight on cryptography, parameter manipulation, and exception management.
How you will check your progress
• Checkpoint
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-1
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
Unit objectives
IBM ICE (Innovation Centre for Education)
IBM Power Systems
After completing this unit, you should be able to:
• Get an overview of cryptography
• Gain insight on parameter manipulation
• Comprehend exception management
© Copyright IBM Corporation 2016
Figure 5-1. Unit objectives
Notes:
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-2
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
Introduction (1 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
Introduction to cryptography, parameter manipulation, & exception management
• Cryptography requires the understanding of the following:
–
–
–
–
–
–
–
–
Basics of cryptography
Control objectives of cryptography
Requirements of cryptography
Insecure cryptographic storage
Environment affected for cryptography
Cryptographic vulnerability
Security verification
Manual approach
© Copyright IBM Corporation 2016
Figure 5-2. Introduction (1 of 2)
Notes:
Basics of Cryptography
To secure the data and make sure it remains unchanged and private, most of the applications use
cryptography. Top threats of using cryptography:
• Poor key generation or key management
• Weak or custom encryption
• Checksum spoofing
Control objectives of cryptography
Insure that a verified application satisfies the followings requirements:
• Errors are handled in correctly way and all cryptographic elements fail in a secure mode
• When randomness is needed there should be used a suitable random number generator.
• The access to keys is managed in a safe way.
Need to verify the followings:
• All cryptographic components fail safely.
• Error handling should be in a way that does not enable oracle padding.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-3
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
• All random number, random GUIDs random file name, and random strings are generated using the
random number generator and that generator should be cryptographic module’s approved.
• Cryptographic should be validated against FIPS 140-2.
• There should a clear and detailed policy for how cryptographic keys are handled.
• All customers of cryptographic services should not have direct access to key material.
• Isolate cryptographic processes, including master secrets and consider the use of a hardware key vault
(HSM).
• Communication should be through secured channels.
• keys and secrets should become zero after destroyed.
• All keys and passwords should be replaceable at the time of installation.
Insecure Cryptographic Storage
Cryptography has become the main part of web application for securing the sensitive data. Applications often
contain poorly designed cryptography and it can be due to two reason, either they use incorrect ciphers or
they use strong ciphers and make a serious error. These flaws can be the reason of disclosure of data.
Environments Affected
All web application structures are susceptible to unsafe cryptographic storage.
Vulnerability
Careful planning is needed to prevent the cryptographic flaws. The most common problems associated with it
are:
• sensitive data not encrypted.
• Using home developed algorithms
• Unsafe usage of strong algorithms
• Continuous usage of feeble algorithms (MD5, SHA-1, RC3, RC4, etc.)
• Hard coding keys, and storing keys in unprotected stores
Am I Vulnerable to 'Insecure Cryptographic Storage'?
The very first thing which you have to decide is which data is need to be encrypted. For example, passwords,
banking details such as credit card numbers, health records and personal info should be encrypted. For such
type of data insure:
• Where the data is stored for long term it should be encrypted and basically in backups of the data.
• Only authorised user should have access of decrypted data.
• Very strong encryption algorithm should be used.
• To protect from unauthorised users, a strong key should be created.
Verifying Security
Automated approaches: The objective is to check that the application properly encrypts the sensitive data in
storage. Vulnerability scanning tools are not much helpful in verifying cryptographic storage. Use of known
cryptographic APIs, can be detected with code scanning tool but it is unable to detect it is being used
correctly or if the encryption is executed in an outside module.
Manual approaches
Testing is unable to confirm cryptographic storage like scanning. Code review is the most beneficial way to
conform encryption of data by an application. Also it helps to check that the key management and
mechanism are properly implemented or not. In some cases, it examines the external system’s configuration
if required.
Protection
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-4
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
The most significant point of view is to make certain that sensitive data that should be encrypted is really
encrypted. And one more thing you should ensure that the cryptography implemented correctly. As there are
numerous ways of using cryptography inadequately,
Following recommendations need to be taken while handling cryptographic materials
• Try to ignore creation of cryptographic algorithms.
• Always use approved public algorithms such as SHA-256, AES and RSA public key cryptography or
better for hashing.
• Use safer alternatives like SHA-256 instead of weak algorithms such as MD5 / SHA 1.
• Always generate keys offline
• Store secret keys carefully and never transmit private keys through unsafe channels.
• Ensure that the MQ access details, credentials like database are accurately secured, properly encrypted
and not easily decrypted by local users.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-5
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
Introduction (2 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
Introduction to cryptography, parameter manipulation, & exception management
• Prevention from Insecure Cryptographic Storage can be achieved by adopting following techniques:
–
–
–
–
–
–
Plan to protect data from insider attack and external user Seeing the threats.
Encrypt all data in a manner that protects against these threats.
Encrypt all offsite backups but the keys are backed up and managed separately.
Use always strong keys and appropriate strong standard algorithms and key management is in place.
Hash the passwords with a strong standard algorithm.
Passwords and all keys are protected from unauthorized access.
© Copyright IBM Corporation 2016
Figure 5-3. Introduction (2 of 2)
Notes:
Prevention from Insecure Cryptographic Storage
• Plan to protect data from insider attack and external user Seeing the threats.
• Encrypt all data in a manner that protects against these threats.
• Encrypt all offsite backups but the keys are backed up and managed separately.
• Use always strong keys and appropriate strong standard algorithms and key management is in place.
• Hash the passwords with a strong standard algorithm.
• Passwords and all keys are protected from unauthorized access.
You must protect cardholder data Under PCI Data Security Standard requirement. For merchants and anyone
else dealing with credit cards, PCI DSS compliance is compulsory by 2008. Good practice is to never store
private data like PAN card details, magnetic stripe information.
For example, you are NEVER allowed to store the CVV number (the three-digit number on the rear of the
card) under any situations, if you store the PAN, the DSS compliance requirements are significant
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-6
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
Poor Key Generation or Key Management
(1 of 4)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Countermeasures to address the threat of key management and poor key contain are as follows:
–
–
–
–
–
–
–
–
–
–
–
–
–
–
Always use built-in encryption procedures containing secure key management.
Store the key in a restricted place Use robust random key generation utilities
Use DPAPI to Encrypt the encryption for added security
Terminate keys on a regular basis
In reality cryptography is a challenging control to implement. Issues range from:
False sense of security
In-house developed and untested encryption routines
Use of untrusted and unsupported encryption routines
System performance
System/data recovery
Key management and recovery
Algorithm type/strengths
Key lengths
Key/random number generation
© Copyright IBM Corporation 2016
Figure 5-4. Poor Key Generation or Key Management(1 of 4)
Notes:
Poor Key Generation or Key Management
If attackers have access to the encrypted keys, they can decrypt it and can create encryption keys. It can
happen when keys are generated in random manner and poorly managed. Attackers can decrypt encrypted
data if they have access to the encryption key or can derive the encryption key. Attackers can discover a key
if keys are managed poorly or if they were generated in a non-random fashion. Countermeasures to address
the threat of key management and poor key contain:
• Always use built-in encryption procedures containing secure key management. Data Protection
application programming interface (DPAPI) is an example of an encryption service provided on Windows
2000.
• Store the key in a restricted place Use robust random key generation utilities— for example, in a registry
key secured with a restricted ACL — if you use an encryption mechanism that requires you to generate or
manage the key.
• Use DPAPI to Encrypt the encryption for added security.
• Terminate keys on a regular basis.
Employing cryptography is not a complete solution to data security. Cryptography can be employed to
provide:
• Confidentiality (data is understood by authorised parties only)
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-7
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
• Integrity (data is not altered in transit)
• Authentication (data originates from a specific party)
In reality cryptography is a challenging control to implement.
Issues range from:
• False sense of security
• In-house developed and untested encryption routines
• Use of untrusted and unsupported encryption routines
• System performance
• System/data recovery
• Key management and recovery
• Algorithm type/strengths
• Key lengths
• Key/random number generation
Threat Agents
Application Specific
Take in account the users of your system. Would they like to gain access to secured data for which they aren’t
authorized? What about internal administrators?
Example Attack Scenarios
• To prevent exposure to end users an application encrypts credit cards in a database. However, the
database is set to automatically decrypt queries against the credit card columns, allowing an SQL
injection flaw to retrieve all the credit cards in clear text.
• The system should have been designed to allow to decrypt only back end applications not the front end
application.
• A backup tape is made of encrypted health records, but the encryption key is on the same backup. The
tape never come to at the backup centre.
• To store everybody’s passwords, the password database uses unsalted hashes. Properly salted hashes
would have taken over 3000 years while all the unsalted hashes can be brute forced in 4 weeks.
• Uncertain permits when generating secret key, allowing spoofing
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-8
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
Poor Key Generation or Key Management
(2 of 4)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Centralized Key Management
© Copyright IBM Corporation 2016
Figure 5-5. Poor Key Generation or Key Management (2 of 4)
Centralized Key Management
Looking at the pervasiveness of encryption today, you can understand the challenge an organization faces
with managing the cryptography infrastructure and the encryption keys and certificates for their IT
infrastructures. Financial institutions use encryption to secure payments as they face compliance
requirements from the Payment Card Industry (PCI): the PCI-PIN and PCI-DSS requirements. Other
organizations have to deal with the protection of personal data, for example, the public sector, insurance
companies, and healthcare providers. They must comply with complex regulations, such as the Health
Insurance Portability and Accountability Act (HIPAA) and the Data Protection Directive. By using the key
management service such as IBM Enterprise Key Management Foundation, organizations can centralize the
key management effort and, in this way, simplify their key management processes. Simplified and unified
processes are an important step toward compliance. The foundation is built around a workstation that utilizes
a key management application and cryptographic co-processor for secure key generation. The other main
component in this tool is the key repository database that is often deployed on an IBM system. From the
workstation, keys are pushed to the supported platforms. The following figure shows the IBM Enterprise Key
Management Foundation overview.
The foundation provides business value for all organizations that are required to manage and maintain
encryption keys in their IT infrastructure. The features of the tool include:
• Centralized key management: The foundation provides centralized key management for the
organization, concentrating the key management effort to a single organizational entity, with trained
personnel that use a common set of procedures.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-9
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
• Compliance: The foundation has been used for more than 2-decade years by financial institutions that
needed to be compliant with the card association's rules for processing PIN-based transactions. The
solution is policy driven, and an organization can configure a setup where administrators create
templates for keys that can be used over and over again when renewing keys for IT applications.
Furthermore, it can be configured to require dual control for all or exactly those operations that
organizations require. When dealing with key parts, the system keeps track of which users have handled
which key parts. All key management operations are logged in the systems database and optionally in
the System Management Facility (SMF).
• Business-oriented solutions: Beyond the basic key management capabilities, the foundation offers a
number of solutions for various business purposes such as ATM Remote Key Loading (RKL); Europay,
MasterCard, and Visa (EMV®)
• Certificate management: The ever-growing use of cryptography for securing transactions has resulted
in an intensive use of certificates. Certificates need to be managed, particularly because they have a
limited lifetime. Certificate expiration can often be linked as the direct cause of IT application or server
downtime. To address this issue, a certificate management model has been developed for the
foundation. The model consists of four phases: In the discovery phase, the network and servers are
scanned for certificates. Discovered certificates are checked against the system's database and new
certificates can be enrolled in the system in the enrolment phase. The monitoring phase is an ongoing
phase, where the database is scanned for certificates that will expire in the near future. Notifications are
issued for expiring certificates. In the management phase, the certificates are renewed and installed on
the servers, the old certificate is decommissioned, and the new certificate enters the monitoring phase.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-10
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
Poor Key Generation or Key Management
(3 of 4)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Components of Centralized Key Management
– The workstation
• All key management operations that involve human interaction are carried out at the workstation
– The key repository
• Keys and their metadata are stored in an IBM database
– The agent
• The agents are installed on servers where either the key repository resides, or where there are
keystores to be managed
© Copyright IBM Corporation 2016
Figure 5-6. Poor Key Generation or Key Management (3 of 4)
Notes:
Components of Centralized Key Management
• The workstation: All key management operations that involve human interaction are carried out at the
workstation. The workstation uses an IBM cryptographic co-processor installed for secure generation of
the keys. The key management application is installed on the workstation, and operators can use smart
cards for authentication to the application, if two-factor authentication is required. The smart cards can
also be used to store the master key. If keys need to be printed, a printer can be attached to the
workstation.
• The key repository: Keys and their metadata are stored in an IBM database. This can be deployed on
any server in the organization, although it is typically deployed on an IBM system when this platform is
available, or on one of the servers. The workstation connects to the database using Java Database
Connectivity (JDBC) or an agent. The network protocol is always TCP/IP.
• The agent: The agents are installed on servers where either the key repository resides, or where there
are keystores to be managed. An agent that only manages keystores is referred to as a "crypto agent",
and an agent that manages the repository is called a "database agent". The crypto agent is required to
push a key to the Integrated Cryptographic Service Facility (ICSF) on the IBM system. The agent serves
both as database and crypto agent.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-11
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
Poor Key Generation or Key Management
(4 of 4)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Utility of Centralized Key Management
– Many banks today have separated the issuing and the authorization systems by deploying them on separate IBM
system logical partitions (LPARs). This requires that the cryptographic keys for the payment cards are available on
those systems.
• Key Management with two Parallel Sysplex systems
– The figure shows a system configuration with two IBM System z® servers, each with two LPARs.
• Installation of the Centralized Key Management
– In order to deploy a complete IBM Enterprise Key Management Foundation system, both a workstation and a server
with the database are required.
© Copyright IBM Corporation 2016
Figure 5-7. Poor Key Generation or Key Management (4 of 4)
Notes:
Utility of Centralized Key Management
Financial institutions both issue payment cards (credit or debit cards) to their customers and also authorize
the respective transactions when the cards are used in ATMs or at points-of-sale. Many banks today have
separated the issuing and the authorization systems by deploying them on separate IBM system logical
partitions (LPARs). This requires that the cryptographic keys for the payment cards are available on those
systems. Scenario: Let us look at an example where the bank needs to issue and verify the "card verification
value" (CVV). In this case, the key that can generate the CVV needs to be installed on the issuing system,
and an instance of the key that can verify the CVV has to be installed on the authorization system.
Key Management with two Parallel Sysplex systems
The figure shows a system configuration with two IBM System z® servers, each with two LPARs. Three of
these LPARs are grouped into an IBM Parallel Sysplex® that runs the authorization system (Sysplex 1 in the
diagram), while the issuing system is installed in Sysplex 2. To accomplish this key distribution, a database
agent that can manage both DB2 and ICSF is installed in z/OS 2A, and crypto agents that can manage ICSF
are installed in all three LPARs in Sysplex 1. Since these LPARs share the cryptographic key data set
(CKDS), only one crypto agent needs to receive a key in order to install it in all three LPARs.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-12
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
Installation of the Centralized Key Management
In order to deploy a complete IBM Enterprise Key Management Foundation system, both a workstation and a
server with the database are required. If you do not want to make use of the workflow capabilities or if your
applications do not need to use the attributes of the keys in the repository, the database can be deployed on
the workstation.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-13
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
Weak or Custom Encryption
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Example Attack Scenarios
–
–
–
–
–
To prevent exposure to end users an application encrypts credit cards in a database
The system should have been designed to allow to decrypt only back end applications not the front end application.
A backup tape is made of encrypted health records, but the encryption key is on the same backup
To store everybody’s passwords, the password database uses unsalted hashes
Uncertain permits when generating secret key, allowing spoofing
© Copyright IBM Corporation 2016
Figure 5-8. Weak or Custom Encryption
Notes:
Weak or Custom Encryption
Take in account the users of your system. Would they like to gain access to secured data for which they aren’t
authorized? What about internal administrators?
Example Attack Scenarios
• To prevent exposure to end users an application encrypts credit cards in a database. However, the
database is set to automatically decrypt queries against the credit card columns, allowing an SQL
injection flaw to retrieve all the credit cards in clear text.
• The system should have been designed to allow to decrypt only back end applications not the front end
application.
• A backup tape is made of encrypted health records, but the encryption key is on the same backup. The
tape never come to at the backup centre.
• To store everybody’s passwords, the password database uses unsalted hashes. Properly salted hashes
would have taken over 3000 years while all the unsalted hashes can be brute forced in 4 weeks.
• Uncertain permits when generating secret key, allowing spoofing
When implementing encryption, it is vital to:
• Understand the business and security requirements
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-14
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
• Work closely with the business information and UK Security technical teams
• Do not attempt to develop an encryption routine yourself
• Do not use untrusted or unsupported encryption routines
• Use only strong, approved and supported encryption routines
• Document the solution
• Test the solution thoroughly (encrypt, decrypt, recover)
• Ensure the key management system (manual or IT-based) is tested thoroughly and adequate training
provided to support staff. The service must be capable of retrieving encrypted data for criminal
investigations.
• Apply suitable key lengths
Attack Vectors
Exploitability: Difficult
Attackers don’t break the crypto, they find keys, get clear text copies of data, or access data via channels that
automatically decrypt.
Security Weakness
Prevalence: Uncommon. Detectability: Difficult
Inadequate Encryption Strength
The software stores or transmits sensitive data using an encryption scheme that is theoretically sound, but is
not strong enough for the level of protection required. A weak encryption scheme can be subjected to brute
force attacks that have a reasonable chance of succeeding using current attack methods and resources.
Common Consequences
Scope: Access Control / Confidentiality
Effect: Technical Impact: Bypass protection mechanism / An attacker may be able to decrypt the data using
brute force attacks.
Potential Mitigations
Use strong cryptographic algorithm
Weak Encryption
1. Insecure Cryptographic Storage
2. Insecure Communication
3. Insecure Storage
Attack Pattern Name
1. Brute Force
2. Encrypting Brute Forcing
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-15
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
Basics of Parameter Manipulation
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Query String Manipulation
– Protection from Query String Manipulation can be sought by
• Use a session identifier to identify the client and store sensitive items in the session store on the
server
• Select HTTP POST instead of GET to submit forms
• Encrypt query string parameters
• Form Field Manipulation
– Protection from Query String Manipulation can be sought by following bellow practices
• Never rely on client-side validation; always validate input from server-side
• Avoid hidden fields, using single session token to refer server-side stored cache memory
• Concatenate the name and value pairs together into a single string and append a secret key to the
end of the string
© Copyright IBM Corporation 2016
Figure 5-9. Basics of Parameter Manipulation
Notes:
Parameter manipulation attacks relies on the modification of the parameter data sent between the client and
Web application. Top parameter manipulation threats include query string manipulation, form field
manipulation, cookie manipulation, and HTTP header manipulation. Parameter manipulation is a relatively
simple process and can be a very effective method of compromising web applications security by making
applications perform activities which they should not be permitted to do. Attackers may take advantage of
poorly designed or written applications to change such things as prices of goods being ordered by altering
HTTP headers or session tokens present in cookies. Application layer cryptographic technique is needed to
protect data. SSL will not protect against this type of attack, as data is manipulated before it is sent to the web
application server.
Query String Manipulation
Basics of Query String Manipulation
The query strings which are displayed in URL can easily be manipulated by user which passed through HTTP
GET. The application is vulnerable to attack if it relies on the query string values for making decisions
regarding security.
Protection from Query String Manipulation
• Use a session identifier to identify the client and store sensitive items in the session store on the server.
• Select HTTP POST instead of GET to submit forms.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-16
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
• Encrypt query string parameters.
Form Field Manipulation
Basics of Form Field Manipulation
HTTP POST protocols are used to send the values of HTML to server in plain text. This can consist both the
hidden form field and visible. The Form field can easily be manipulated by attackers. Thus the application
which trust the values of form fields become the victim of the form field manipulation. So for preventing this
always prefer to choose session identifiers instead of hidden form fields. Information selected or entered is
typically stored as form field values and sent to the application via HTTP requests (GET or POST). HTML can
also store field values as hidden fields, which are not rendered to the screen by the browser, but collected
and submitted as parameters during form submissions. Irrespective of the field type (drop down, check or text
boxes, etc.), they can all be manipulated by the user to submit whatever values they choose. This can be
easily achieved in most cases by viewing the source and saving the file for editing and subsequently
re-loading the manipulated file.
Protection from Form Field Manipulation
• Never rely on client-side validation; always validate input from server-side.
• Avoid hidden fields, using single session token to refer server-side stored cache memory. Whenever user
property needs to be matched, session cookie with its session table must be checked and then it must be
pointed to the user’s data variables in the database or server-side cache.
• Whenever it is not possible to implement the above solution and the use of hidden field is compulsory,
concatenate the name and value pairs together into a single string and append a secret key to the end of
the string.
• When the form is submitted, the name and value pairs are concatenated once again along with the secret
key into the incoming form message. If encrypted and arrived data do not match, then it indicates that the
hidden form field is manipulated. This method can also be used in URLs to protect against manipulation
of parameters.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-17
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
Cookie Manipulation
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Cookie manipulation refers to the modification made in cookies. Cookies are vulnerable to be
manipulated easily by client. There are so many tools an attacker can use to make modification in
cookies
• For protection from Cookie Manipulation
–
–
–
–
–
–
–
Do not trust user input for values that are already known to you
Use one session token to refer server-side stored cache memory
Do not store personal data or financial information in cookies
Do not store authentication details in cookies
Ensure session IDs are hashed if stored in cookies
Encrypt contents of cookies using approved crypto APIs
Label cookie as ‘Secure’ to prevent browsers sending it over non-secure connection
© Copyright IBM Corporation 2016
Figure 5-10. Cookie Manipulation
Notes:
Basics of Cookie Manipulation
Cookie manipulation refers to the modification made in cookies. Cookies are vulnerable to be manipulated
easily by client. There are so many tools an attacker can use to make modification in cookies. Attackers
modify the cookies to gain unauthorised access to web pages. SSL is used for safety of cookies but it fails to
prevent any modification done on client computer. To get ride from cookie manipulation, always use
encryption and HMAC. If cookies store sensitive information, this information could be used to mount an
attack or to commit a fraud. All forms of cookies may be tampered with prior to sending back to the server.
The level of cookie manipulation is contingent upon the use the cookie is put to. Many cookies are Base64
encoded which does not offer any cryptographic protection.
Protection from Cookie Manipulation
• Do not trust user input for values that are already known to you
• Use one session token to refer server-side stored cache memory
• Do not store personal data or financial information in cookies
• Do not store authentication details in cookies
• Ensure session IDs are hashed if stored in cookies
• Encrypt contents of cookies using approved crypto APIs
• Label cookie as ‘Secure’ to prevent browsers sending it over non-secure connection
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-18
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
HTTP Header Manipulation
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• The client and server pass the data or info through the HTTP headers. The client makes request header
and the receiver make the response header to that request. When it comes to make a decision, if your
application trust headers then application is vulnerable to attack
• For determining from where the client has requested, do not trust the HTTP headers. HTTP header are
used to pass control data from web clients to web servers for HTTP requests and vice versa for HTTP
responses. The majority of applications ignore them.
• For availing protection from HTTP Header Manipulation
– Do not rely on headers without additional security mechanisms
© Copyright IBM Corporation 2016
Figure 5-11. HTTP Header Manipulation
Notes:
HTTP Header Manipulation
The client and server pass the data or info through the HTTP headers. The client makes request header and
the receiver make the response header to that request. When it comes to make a decision, if your application
trust headers then application is vulnerable to attack. So for determining from where the client has requested,
do not trust the HTTP headers. HTTP header are used to pass control data from web clients to web servers
for HTTP requests and vice versa for HTTP responses. The majority of applications ignore them. For
examples: Referrer header normally contains the URL of the page which the request originated. Developer’s
may choose to check this header in order to confirm the request originated from a trusted URL (e.g. their
own) it stops attackers from modifying the forms, saving web pages, and posting from another computer.
There is an option of selecting language labels, the user can select required language labels and can pass it
to the database to check through. If the content of the header is sent verbatim to the database, an attacker
can inject SQL commands. An attacker may be able to launch a path traversal attack.
Protection from HTTP Header Manipulation
• Do not rely on headers without additional security mechanisms
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-19
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
Basics of Exception Management (1 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Exceptions are allowed to propagate to the client can reveal internal implementation details. This details
make no sense to the end user, but are very helpful to the attackers
• The basic countermeasure for exception handling is to disclose minimal information following an
exception.
– Information Disclosure
• Revealing personally identifiable information (PII) such as passwords and credit card data, plus
information about the application source and/or its host machines
– Attacker Reveals Implementation Details
• Attacker can use number of methods to obtain information that could provide a useful basis on
which to perpetrate an attack on websites or the supporting infrastructures
© Copyright IBM Corporation 2016
Figure 5-12. Basics of Exception Management (1 of 2)
Notes:
Basics of Exception Management
Exceptions are allowed to propagate to the client can reveal internal implementation details. This details
make no sense to the end user, but are very helpful to the attackers. Applications that do not use exception
handling are subject to denial of service attacks. In order to protect against exception handling, define a
standard approach to structured exception handling and specify generic error messages to be returned to the
client. The basic countermeasure for exception handling is to disclose minimal information following an
exception.
Information Disclosure
Basics of Information Disclosure
Revealing personally identifiable information (PII) such as passwords and credit card data, plus information
about the application source and/or its host machines. Common causes: Allowing an authenticated user
access to other users’ data, allowing sensitive information on unsecured communication channels, selecting
poor encryption algorithms and keys. Preventive measures: Store PII on a session (transitory) rather than
permanent basis, use hashing and encryption for sensitive data whenever possible, match user data to user
authentication.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-20
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
Attacker Reveals Implementation Details
Attacker can use number of methods to obtain information that could provide a useful basis on which to
perpetrate an attack on websites or the supporting infrastructures. However, it is possible, in many areas, to
prevent this form of unwanted disclosure by following simple guidelines. Client-side Comments: Adding and
maintaining comments in source code has been a standard developer practice for years to assist in later
support. This practice often extends to HTML pages which can reveal sensitive data about the structure of the
website, its underlying infrastructure or members of staff. Comments which are often left in HTML pages
include directory structures, server names, IP addresses, errors, debug information, developer names,
change/problem numbers, email addresses, phone numbers.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-21
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
Basics of Exception Management (2 of 2)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Protection from Information Disclosure can be sought by:
– Remove comments (except Copyright comments!) from code before it is migrated to production services.
– Ensure quality assurance processes include provision to verify that all comments are removed prior to migration to
production.
– Debug Commands: As with source code comments, it is often standard developer practice to include debug switches
in HTML to allow them to switch on additional levels of logging or reporting. Permitting this code (and the server-side
logic to interpret it) into production services
© Copyright IBM Corporation 2016
Figure 5-13. Basics of Exception Management (2 of 2)
Notes:
Protection from Information Disclosure
• Remove comments (except Copyright comments!) from code before it is migrated to production services.
• Ensure quality assurance processes include provision to verify that all comments are removed prior to
migration to production.
• Debug Commands: As with source code comments, it is often standard developer practice to include
debug switches in HTML to allow them to switch on additional levels of logging or reporting. Permitting
this code (and the server-side logic to interpret it) into production services result in serious vulnerability,
gaining the attacker escalated privileges to the services and underlying infrastructure. Mitigation:
Implement a standard debugging process, using specific tools and practices making it easier to remove
this functionality when required. Consider automating debug function removal and ensure all debug
functionality is removed prior to migration to production. Prior to migration to production perform tests to
ensure the server-side debug logic has been removed.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-22
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
Denial of Service (1 of 3)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Flooding - sending many messages or simultaneous requests to overwhelm a server
• Lockout - sending a surge of requests to force a slow server response by consuming resources or
causing the application to restart
• Common causes
– Placing too many applications on a single server
– Placing conflicting applications on the same server
– Neglecting to conduct comprehensive unit testing
• Preventive measures include
– Filter packets using a firewall
– Use a load balancer to control the number of requests from a single source
– Use asynchronous protocols to handle processing-intensive requests and error recovery
© Copyright IBM Corporation 2016
Figure 5-14. Denial of Service (1 of 3)
Notes:
Basics of Denial of Service
Flooding—sending many messages or simultaneous requests to overwhelm a server. Lockout—sending a
surge of requests to force a slow server response by consuming resources or causing the application to
restart. Common causes: placing too many applications on a single server or placing conflicting applications
on the same server, neglecting to conduct comprehensive unit testing.
Preventive measures include filter packets using a firewall, use a load balancer to control the number of
requests from a single source, use asynchronous protocols to handle processing-intensive requests and
error recovery. If attackers try to probe into a web application by providing intentionally incorrect input, they
have two objectives in their head. The first one is to create exceptions in order to reveal valuable data and the
second is to crash the web application process.
This can happen if the exceptions are not accurately trapped and handled. Steps to help stop application
level denial of services include carefully authenticating all input data at the server side and use exception
handling methodology in the client side. A message is sent by the user in a typical connection in order to ask
the server for authentication.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-23
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
This authentication approval is returned from the server-side to the client-side machine. When the user
receives this approval then only he is allowed to access the server. In a denial of service (DoS) attack, many
requests of authentication is sent by the user to the server which fills it up. Now when the server tries to send
the approval of the requested authentication it is not able to send it as all the report have false return
addresses. Thus the connection is closed by the server after waiting for more than a minute.
The attacker now sends a new batch of requests which are forged and the process of the server trying to give
access begins again. For some time now, DDoS/DoS attack have been pausing a lot of problem. These
attacks are successful in many cases as the organization do not update their plans of incident response nor
do they turn their technologies for mitigating threads.
Traffic-flooding and high-volume techniques are the primarily used techniques to target the service provider.
A DoS attack can be employed by a malicious actor while it is going after some critical information in a
database of an e-commerce organization.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-24
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
Denial of Service (2 of 3)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Following is an example of how a typical DoS attack can be carried out against a target:
– Unsuspecting users are directed by a malicious hyperlink or a phishing email to a website where their systems can
get infected by malwares and can be placed under the reason due to which malicious activities are taking place.
– The machines which have been compromised now a wait for the instructions from the bot controller in order to attack
a target. This is not known by the user. These bots remain idle for many days before they come to action and attack
the system.
– The machines which have been compromised now launched DDoS or DoS attacks at the command of the bot
controller against the target. This is often carried out by using the UPD ports 53, 80, 443, 514, or the port number 80,
443 and 110 of TCP.
– The systems which are targeted are often overrun with traffic and are forced offline.
© Copyright IBM Corporation 2016
Figure 5-15. Denial of Service (2 of 3)
Notes:
Detailed Description of Denial of Service
Most web applications are vulnerable to denial of service attack. For example, SYN floods is a type of
network denial service attack. A web application cannot precisely distinguish between an attack and original
traffic. There are various elements that can lead to such trouble, and IP address is not of much advantage as
an identification credential. It is very hard to separate out vicious traffic because there is no authentication
technique to state from where an HTTP request has arrived. So the question arises, how would an
application assure the difference between a real attack and a genuine traffic, when numerous operators are
all hitting reload simultaneously. This can occur due to any temporary issue on the web application or it may
be slashdotted, a short-term surge in the number of visitants to a web application, thereby resulting in
slowdown or at extreme case crash of the server serving the web application. Usually, most servers can deal
with hundred parallel users. A single attacker can create plenty of traffic from an individual host to merge
several applications. If sessions are connected to a peculiar server, load balancing can make these attacks
harder. This is the reason an application’s session data is made as small as possible. And it’s difficult to start
a new session. Once attackers acquire necessary resource, they can stop authenticating users to access the
system. Bandwidth, database connections, disk storage, CPU, memory, threads, or application specific
resources comes under the category of limited resources. All these resources can easily be attacked. For
example, a site may generate many data base queries for each http if it lets Unauthorised users to request.
Then an unauthorised user can send many request so that database get used up and there will be none left
to service the real or legitimate users. Furthermore, an attacker can prevent the real user to access their
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-25
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
account by providing wrong credentials again and again until the system lock out the account, Or the attacker
might request a new password for a user, forcing them to access their email account to regain access. There
are a wide variety of such type of attacks, most of which can be easily launched with a few lines of Perl code
from a low powered computer. While there are no perfect defences to these attacks, it is possible to make it
more difficult for them to succeed.
Following is an example of how a typical DoS attack can be carried out against a target:
1. Unsuspecting users are directed by a malicious hyperlink or a phishing email to a website where their
systems can get infected by malwares and can be placed under the reason due to which malicious
activities are taking place.
2. The machines which have been compromised now a wait for the instructions from the bot controller in
order to attack a target. This is not known by the user. These bots remain idle for many days before they
come to action and attack the system.
3. The machines which have been compromised now launched DDoS or DoS attacks at the command of
the bot controller against the target. This is often carried out by using the UPD ports 53, 80, 443, 514, or
the port number 80, 443 and 110 of TCP.
4. The systems which are targeted are often overrun with traffic and are forced offline.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-26
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
Denial of Service (3 of 3)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Affected Environments from Denial of Service
– The susceptibility of denial of service is present in nearly all identifiable web application, application server, and web
server environment.
• Determination of Denial of Service Vulnerability
– One important test is how many requests per second your application can hold
– To test from a single IP address is useful as it will give you an idea of how many requests an attacker will have to
produce in order to harm your site. To come to a decision about if any resources can be used to make come into
existence denial of Service, you should observe each one to see if there is a way to exhaust it
• Protection from Denial of Service Attack
– The time taken by the database to give response get delayed when server resources are overloaded by database
DOS
– Query rates, rates incurred for connection and various other rates for each user of the database are limited by the
server resource. This prevention step is accomplished by Connection Controls.
– Database servers can be crashed if attackers exploit platform vulnerabilities. Such attacks can be prevented by IPS
and protocol validation.
– Query access control is provided by Dynamic Profiling that can detect any queries beforehand and prevent DOS
attacks
© Copyright IBM Corporation 2016
Figure 5-16. Denial of Service (3 of 3)
Notes:
Affected Environments from Denial of Service
The susceptibility of denial of service is present in nearly all identifiable web application, application server,
and web server environment.
Determination of Denial of Service Vulnerability
Coming to a decision about whether you are open to attack Is one of the difficult parts of denial of Service
attacks. JMeter (load testing instruments) can produce web traffic so that you can test certain aspects of how
your place acts under weighty amount. Certainly one important test is how many requests per second your
application can hold. To test from a single IP address is useful as it will give you an idea of how many
requests an attacker will have to produce in order to harm your site. To come to a decision about if any
resources can be used to make come into existence denial of Service, you should observe each one to see if
there is a way to exhaust it. You should especially focus on what an unauthenticated user can do. But, you
should analyse at what a certain user can do as well, unless you Trust all of your users.
Protection from Denial of Service Attack
As there is no perfect to protect against denial of services, so defending against it is very hard. The resources
allocated to any user should be limited. You can drop another request if you are working on one. Try to handle
one request at one time, as authenticated users are able to establish quotas so you can limit the load a user
can put on system. For unauthorised user you should avoid access to any database unnecessarily. You
should take care about the error handling scheme whether it is going to affect any other operations. A
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-27
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
distributed denial-of-service (DDoS) is where the attack sources are many, often thousands of, unique IP
addresses. Criminal perpetrators of DoS attack often target sites or services hosted on high-profile web
servers such as banks, credit card payment gateways; but motives of revenge, blackmail or activism can be
behind other attacks. Multiple level protection i.e. at network, application, and database levels is requires
against DOS. Specifically focusing on database response, the recommended countermeasures are response
timing control, IPS, access control query and control of connection rate deployment.
• The time taken by the database to give response get delayed when server resources are overloaded by
database DOS
• Query rates, rates incurred for connection and various other rates for each user of the database are
limited by the server resource. This prevention step is accomplished by Connection Controls.
• Database servers can be crashed if attackers exploit platform vulnerabilities. Such attacks can be
prevented by IPS and protocol validation.
• Query access control is provided by Dynamic Profiling that can detect any queries beforehand and
prevent DOS attacks.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-28
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
Checkpoint
IBM ICE (Innovation Centre for Education)
IBM Power Systems
1. Cryptography is:
A.
B.
C.
D.
An Art
A Science
Both Art as well as Science
Neither Art nor Science
2. RSA in cryptography stands for:
A.
B.
C.
D.
Rivest Shamir Adelman
Real Scalable Algorithm
Royal Society of America
Ridley Scott Algorithm
3. Which of the following is considered cryptographic algorithm?
A.
B.
C.
D.
Symmetric key
Asymmetric key
Hash Function
All of the above
4. Symmetric key cryptographic algorithm uses the same key for encryption as well as decryption:
A. True
B. False
© Copyright IBM Corporation 2016
Figure 5-17. Checkpoint
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-29
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
Checkpoint
IBM ICE (Innovation Centre for Education)
IBM Power Systems
5. Asymmetric key cryptographic algorithm uses:
A.
B.
C.
D.
Public key
Private key
Both Public as well as Private key
Neither Public key nor Private key
6. Which of the following is not a parameter manipulation threat?
A.
B.
C.
D.
Query String Manipulation
Form Field Manipulation
Cookie Manipulation
Encryption Manipulation
7. DDoS stands for:
A.
B.
C.
D.
Dispersed Denial of Service
Distributed Denial of Service
Diluted Denial of Security
Directed Disk Operating System
© Copyright IBM Corporation 2016
Figure 5-18. Checkpoint
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-30
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
Checkpoint
IBM ICE (Innovation Centre for Education)
IBM Power Systems
8. Hash collisions are:
A.
B.
C.
D.
Failure of a given cryptographic hash function to complete successfully
Repetitions within a message digest that indicate weakness in the hash algorithm
Matching message digests found during the verification of a digital signature
Two different input messages that result in the same message digest value
9. A security architect working for a large financial institution has been asked to evaluate a variety of
cryptographic algorithms that are being considered as candidates for a proprietary Electronic Funds
Transfer (EFT) application.
A. Recommend a symmetric key cryptographic algorithm to provide confidentiality, integrity, and authenticity
protections
B. Recommend that all transactions are digital signed before they are transmitted over an unsafe network
C. Recommend a hybrid solution that combines symmetric and asymmetric cryptography as well as hash functions
D. Recommend a hybrid solution that combines asymmetric cryptography and hash functions
10. Any action that prevents authorized users from executing programs is called
A.
B.
C.
D.
Malware
Spam
Denial of Service
Cross-site scripting
© Copyright IBM Corporation 2016
Figure 5-19. Checkpoint
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-31
V11.0
Unit 5. Introduction to cryptography, parameter manipulation & exception management
Uempty
Unit summary
IBM ICE (Innovation Centre for Education)
IBM Power Systems
After completing this unit, you should be able to:
• Get an overview of cryptography
• Gain insight on parameter manipulation
• Comprehend exception management
© Copyright IBM Corporation 2016
Figure 5-20. Unit summary
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
5-32
V11.0
Unit 6. Auditing & Logging, Countermeasures
Uempty
Unit 6. Auditing & Logging,
Countermeasures
Overview
This unit provides an insight on Auditing & Logging, and their countermeasures.
How you will check your progress
• Checkpoint
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
6-1
V11.0
Unit 6. Auditing & Logging, Countermeasures
Uempty
Unit objectives
IBM ICE (Innovation Centre for Education)
IBM Power Systems
After completing this unit, you should be able to:
• Get an overview of Auditing and logging
• Understand Basic countermeasures to provide security against Web Application Vulnerabilities
© Copyright IBM Corporation 2016
Figure 6-1. Unit objectives
Notes:
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
6-2
V11.0
Unit 6. Auditing & Logging, Countermeasures
Uempty
Introduction to Auditing & Logging,
Countermeasures
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Introduction
– Managing the events and reporting the shortcomings is not the only responsibility of log management process. In
addition to that, log management is also responsible for the protection of the availability, integrity and confidentiality
of its own data. It has to ensure that regular analysis of log data is performed effectively by system, security and
network administrators.
• Basics of Auditing & Logging
– There are a number of possible security exploits, like foot-printing and possible password cracking attempts, that can
occur if not detected in time. These suspicious activities can be detected by using auditing and logging. When proper
log management is being carried out, it would contain log entries in case a suspicious activity occurs, such as
synchronized log entries on multiple servers corresponding to a transaction performed.
• The threats related to auditing and logging include the following:
– Operation denied by the user
– Application exploited
– Tracks covered by the attackers
© Copyright IBM Corporation 2016
Figure 6-2. Introduction to Auditing & Logging, Countermeasures
Notes:
Introduction to Auditing & Logging, Countermeasures
A log is a record of the events befalling in an organization’s systems and networks. Log is made of log
entries. Each log entries comprise computer security related record. These computer security logs are
created by various information related sources. Logs within an organization keep a record of major and minor
incidents pertaining to operations, input and output dealings. Any events that concerns with the organization’s
systems and networks finds a place in the logs. Separate entities are defined in the log management with
each entry corresponding to a distinct event. Most organizations maintain log records related to computer
and network security. The security logs are generated along the lines of sources such as firewalls, antivirus
applications, and intrusion detection and prevention systems, server security software, operating systems,
and networking equipment. Security log management is defined as the process in which computer security
log data is generated transmitted, stored, analysed and disposed. The need for this process has arisen as the
volume of security logs have increased and need a management system for proper storage and study for
conclusions. Log management ensures that there are sufficient briefings available of the security logs and a
proper timeline is maintained in storing these events. A timeline ensures that, in case there are any security
incidents, operational problems, fraudulent activity or policy violations, they are not ignored and are dealt with
utmost urgency. The generated logs can be useful when there is any audit and forensic analysis to be
performed. Apart from that, the logs can also be used to create baselines, internal investigation, identify
operational trends, and future prospective for business development. Log management is also found to be
prone to some shortcomings. One of the fundamental issue that is found to be common with many
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
6-3
V11.0
Unit 6. Auditing & Logging, Countermeasures
Uempty
organizations is the balancing a continuous supply of log data with the limited available quantity of log
management resources. A large number of log sources, inconsistent log data, formats, and timestamps
among resources lead to complications in the storage and generation of logs. Managing the events and
reporting the shortcomings is not the only responsibility of log management process. In addition to that, log
management is also responsible for the protection of the availability, integrity and confidentiality of its own
data. It has to ensure that regular analysis of log data is performed effectively by system, security and
network administrators.
Basics of Auditing & Logging
There are a number of possible security exploits, like foot-printing and possible password cracking attempts,
that can occur if not detected in time. These suspicious activities can be detected by using auditing and
logging. When proper log management is being carried out, it would contain log entries in case a suspicious
activity occurs, such as synchronized log entries on multiple servers corresponding to a transaction
performed. The threats related to auditing and logging include the following:
• Operation denied by the user
• Application exploited
• Tracks covered by the attackers
Identify key parameters for auditing and logging; specify storage, security, and analysis features for log files;
and specify how to flow caller identity across multiple tiers—at the OS or application level. Construction does
not log sensitive data.
Logging
• Specifications followed accordingly in the implementation of the audit trial logging mechanisms
• The vulnerability offered by the unauthorized deletion, modification or disclosure to the application audit
record
Error handling and logging verification requirements
Error handling and logging aims to provide a valuable feedback from the incident response teams,
administrators, and users. The idea of is not to erect piles of logs, but construct a limited amount of high
quality logs offering more value and ignoring the redundancies. More value means it should offer sensitive
data and protection to that data as per the data privacy regulations. Value-based logging should include:
• If not specifically required, avoiding collecting sensitive information
• Logged data is classified accordingly and handled securely
• The log lifetime should be short and no logs should be stored for a long time
Logs become prone to attacks by malicious beings depending upon the sensitivity of data contained within
and thus need to be secured accordingly.
Requirements
1. There should not be any stack traces of sensitive data or error messages being sent with sensitive data in
them, by an application. Such incident could lead to disclosing software/framework sessions, personal
information and session id that could assist an attacker to compromise operations and get away with it
2. The error handling logic in security controls should by default deny any external access
3. Log success and failure events, identified as relevant to security should be logged accordingly by the
security logging controls
4. In case a log is generated that includes necessary information, it should engage a detailed investigation
of the event
5. The intended log viewing software should not encode and execute untrusted data and all such events
must be verified
6. All unauthorized access and modifications of the security logs should be denied
7. Applications should not log important information and should abide by the privacy regulations.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
6-4
V11.0
Unit 6. Auditing & Logging, Countermeasures
Uempty
8. In order to prevent log injection, log entries should contain encoded formats of all field separators and
non-printable symbols
9. Log entries should contain distinguished log fields from trusted and untrusted sources
10. Non-repudiation of important transactions should be allowed in an audit log
11. To prevent unauthorized modification, security logs should do integrity checking
12. Application should run with proper log rotation in case there are logs stored on different partition
Attacker Exploits an Application Without Trace
To detect all suspicious activities without bias, system and application-level auditing is required. In system
and application-level auditing, countermeasures are adopted such as:
• Application level operations designated as critical to be logged
• To audit log-in, log-out events, failed object access attempts, and access to the filesystem, platform-level
auditing to be used
• Log files to be backed-up regularly and regular analysis to be done to isolate suspicious activities
Log Tampering
Web applications maintain logs to track the usage patterns of an application. User logins, administrator
logins, resources accessed, error conditions, and other application-specific information are often maintained
in logs. These logs are used for proof of transactions, fulfilment of legal record retention requirements,
marketing analysis, and forensic incident analysis. An attacker, in an attempt to cover tracks, will usually
delete logs, modify logs, change user information, and otherwise destroy all evidence of the attack.
Attacker Covers His or Her Tracks
To ensure that the attackers are not able to cover their tracks, log files should be well protected. Following
measures can help to achieve this goal:
• Restricted ACLs to be used to secure log files
• Log files to be relocated from their original locations
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
6-5
V11.0
Unit 6. Auditing & Logging, Countermeasures
Uempty
Basic Countermeasures
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Basic Countermeasures to Provide Security against Web Application Vulnerabilities
–
–
–
–
Discover and create baselines for applications
Assess and assign risks and prioritize application vulnerabilities
Shield your application and control damage using appropriate controls
Continuously monitor and review the risks and vulnerabilities associated with applications
© Copyright IBM Corporation 2016
Figure 6-3. Basic Countermeasures
Notes:
Basic Countermeasures
By studying and analysing the approach adopted by attackers, one can come up with counter-tactics to deal
with them. This could essentially prevent or at least minimize the probable damage. A goal-based approach
can be used to identify and categorize threats, identify the weak points and apply necessary
countermeasures. As every attack is different and each attack has to be mitigated with a different approach, it
is impractical to design a countermeasure strategy for each attack. Instead, a general strategy allows ample
tactics to deal with potential threats. Identifying threats is a key point as it allows to identify the
countermeasures needed and create a threat modelling process that minimizes the risks. A structure process
helps in categorizing and prioritizing threats. Additionally, logs must be digitally marked and time-stamped
which creates a trail of transactions versus attacker activity, thus aiding in following the attackers. Separate
logs for system events, network firewall events, and application events should be generated.
• Discover and create baselines:
Basic Countermeasures to Provide Security against Web Application Vulnerabilities
By using security-specific processes to create applications, software development teams can guard against
security violations. Specifically, you can apply several basic guidelines to existing applications and new or
reengineered applications throughout your process to help achieve greater security and lower remediation
costs, such as:
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
6-6
V11.0
Unit 6. Auditing & Logging, Countermeasures
Uempty
Conduct a complete inventory of applications and systems, including technical information (e.g., Internet
Protocol [IP], Domain Name System [DNS], OS used), plus business information (e.g., Who authorized the
deployment? Who should be notified if the application fails?). Next, scan your Web infrastructure for common
vulnerabilities and exploits. Check list serves and bug tracking sites for any known attacks on your OS, Web
server and other third-party products. Prior to loading your application on a server, ensure that the server has
been patched, hardened and scanned. Then, scan your application for vulnerabilities to known attacks,
looking at HTTP requests and other opportunities for data manipulation. And, finally, test application
authentication and user-rights management features and terminate unknown services.
• Assess and assign risks:
Rate applications and systems for risk—focusing on data stores, access control, user provisioning and rights
management. Prioritize application vulnerabilities discovered during assessments. Review organizational,
industry and governmental policy compliance. And identify both acceptable and unacceptable operations.
• Shield your application and control damage:
Stay on top of known security threats and apply available patches to your applications and/or infrastructure. If
you cannot fix a security issue, use an application firewall, restrict access, disable the application or relocate
it to minimize exposure.
• Continuously monitor and review:
Schedule assessments as part of your documented change management process. When you close one out,
immediately initiate a new discovery stage.To help prevent expensive fixes, organizations need to build
application security testing approaches, such as those shown in figure 3, into their development and delivery
process alongside other quality management measures. Manual countermeasures include penetration or
security acceptance testing by a small set of security experts using known tools and scripts. The advantage
of manual testing is that it generates well-targeted tests for specific application functions. The disadvantage
being it limits testing to experts, which may lead to bottlenecks; can lead to a high error rate and recurring
costs; and limits application coverage due to time constraints. On the other hand, automated web application
security testing can be built in one of two methods. Bottom up—Specific tests for individual functions, built by
the code developer. Top down—QA teams build tests from an end-user perspective. The advantage of
automated testing is that offsets expenses with improvements in quality, reduced effort for acceptance testing
and iterative development processes. The disadvantage is that it requires greater overhead to create and
maintain than manual testing requires.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
6-7
V11.0
Unit 6. Auditing & Logging, Countermeasures
Uempty
Basic Countermeasures
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Below are the different testing methodologies used to find the application vulnerabilities
– Black box or system testing
– White box or source testing
– Grey box testing
© Copyright IBM Corporation 2016
Figure 6-4. Basic Countermeasures
Notes:
Some testing methodology
Black box or system testing:
Looks only at system input and output, modifying normal user input to make the application behave in
unintentional ways. The advantage of Black box testing is that it uses well-established automated test tools
that require minimal application knowledge to use. The disadvantages of Black box testing are that it is
possible only when all application components are ready for testing (late staging or production environment);
may produce transactions that are difficult to ignore or reverse through user input mutations; and can obscure
flaws by limiting visibility into the application
White box or source testing:
Assesses individual components for specific functional errors, often in combination with code scanning tools
and peer reviews. The advantage of White box testing is that it uses tools that have established integrations
with developer IDEs, enabling the well-defined discovery of flaws in tested functions. The disadvantages of
White box testing are that it does not uncover requirement and design flaws, may not uncover vulnerabilities
to attacks involving multiple components or specific timing not covered by unit testing; and assumes that
coders are aware of needed security.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
6-8
V11.0
Unit 6. Auditing & Logging, Countermeasures
Uempty
Grey box testing:
Performed using an application-defined framework. Combines black and white box testing to create tests
unavailable via commercial tools. The advantages of Grey box testing are that it provides the most
comprehensive method by combining system- and unit-level testing; provides state- and timing-based tests,
and uses agents or proxies; integrates the framework into the application to monitor data flows and conduct
audits without affecting production data. The disadvantages of Grey box testing are that it requires a
framework to be specified during the inception phase and design activities; and may require as much effort to
build the test framework as to build the application.
In addition to making security an integral part of the application development and delivery process, you can
integrate security tests right into the application you are building to conduct event-driven testing. In this case,
where a user makes a request and the application responds, the test compares the response to an expected
or previously stored response to determine whether the system is operating properly. For example, in figure
3, an application uses a database as its back-end component.
The tester inserts a spy proxy and a verifier into the request flow, telling the verifier what a normal request
should be so that the verifier can compare it with the spy proxy’s actual request. Any service, e-mail, XML or
legacy service can serve as a back end. How you implement the code to review requests depends on the
application architecture. For example, your spy component might be a mock data access object, a proxy or a
class that inherits from the front-end service. You can also create code specifically for a test that you insert
into the data stream to supply reporting data needed by the testing framework. Coordinating the testing
objects gives you comprehensive, fine-grained control of a range of tests. You can perform these tests using
either black-box or white-box testing, improving your chances of catching security problems early in the
lifecycle—before they pose a serious business risk.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
6-9
V11.0
Unit 6. Auditing & Logging, Countermeasures
Uempty
Basic Countermeasures
IBM ICE (Innovation Centre for Education)
IBM Power Systems
• Four strategic countermeasures for protecting Web applications and to increase security awareness
–
–
–
–
–
–
Training
Communication of best practices across all business lines
Monitoring the security status
Categorizing application risk and liability
Set a zero-tolerance enforcement policy
Integrate security testing throughout the development and delivery process
© Copyright IBM Corporation 2016
Figure 6-5. Basic Countermeasures
Notes:
Four strategic countermeasures for protecting Web applications
To address security-related issues as they pertain to Web applications, organizations can employ four broad,
strategic best practices.
Increase security awareness:
This encompasses training, communication and monitoring activities, preferably in cooperation with a
consultant.
Training: Provide annual security training for all application team members: developers, quality assurance
professionals, analysts and managers. Describe current attacks and a recommended remediation process.
Discuss the organization’s current security practices. Require developers to attend training to master the
framework’s prebuilt security functions. Use vendor-supplied material to train users on commercial
off-the-shelf (COTS) security tools, and include security training in the project plan.
Communication: Collect security best practices from across all teams and lines of business in your
organization. Distribute them in a brief document and make them easily accessible on an intranet. Get your IT
security experts involved early and develop processes that include peer mentoring. Assign a liaison from the
security team to every application team to help with application requirements and design.
Monitoring: Ensure that managers stay aware of the security status of every application in production. Track
security errors through your normal defect tracking and reporting infrastructures to give all parties visibility.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
6-10
V11.0
Unit 6. Auditing & Logging, Countermeasures
Uempty
Categorize application risk and liability:
Every organization has limited resources and must manage priorities. To help set security priorities, you can:
• Define risk thresholds and specify when the security team will terminate application services.
• Categorize applications by risk factors (e.g., Internet or intranet vs. extranet).
• Generate periodic risk reports based on security scans that match issues to defined risk thresholds.
• Maintain a database that can analyse and rank applications by risk, so you can inform teams of how their
applications stack up against deployed systems.
Set a zero-tolerance enforcement policy:
An essential part of governing the development and delivery process, a well-defined security policy can
reduce your risk of deploying vulnerable or noncompliant applications. During inception, determine which
tests the application must pass before deployment, and inform all team members. Formally review
requirements and design specifications for security issues during inception and elaboration—before coding
begins. Allow security exceptions only during design and only with appropriate executive-level approval.
Integrate security testing throughout the development and delivery process:
By integrating security testing throughout the delivery lifecycle, you can have significant positive effects on
the design, development and testing of applications. You should base functional requirements on security
tests your application must pass, making sure that your test framework:
Uses automated tools and can run at any point during the development and delivery process
Includes unit and system tests as well as application-level tests
Allows for audit testing in production
Includes event-driven testing
Uses an agile development methodology for security procedures
Can be run during coding, testing, integration, and production activities
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
6-11
V11.0
Unit 6. Auditing & Logging, Countermeasures
Uempty
Checkpoint
IBM ICE (Innovation Centre for Education)
IBM Power Systems
1. The suspicious activity can be detected by using _________:
A.
B.
C.
D.
Auditing and Logging
Analysis and Design
Coding and Testing
All the above
2. Security log management is defined as the process in which computer security log data is generated,
transmitted, stored, analysed, and:
A.
B.
C.
D.
Ended
Disposed
Deleted
Terminated
3. Which of the following is a threat related to auditing and logging?
A.
B.
C.
D.
User denies performing an operation
User is not willing to work
Attacker exploits application and leaves the trace
Attacker exposes his or her tracks
© Copyright IBM Corporation 2016
Figure 6-6. Checkpoint
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
6-12
V11.0
Unit 6. Auditing & Logging, Countermeasures
Uempty
Checkpoint
IBM ICE (Innovation Centre for Education)
IBM Power Systems
4. ______ is process in which an attacker covers tracks by destroying all evidence of the attack.
A.
B.
C.
D.
Denial of service
Track attack
Garbage collection
Log tampering
5. Strategic countermeasures for protecting web applications include:
A.
B.
C.
D.
Increasing security awareness and categorizing application risk and liability
Integrating security testing throughout development and delivery process
Setting a zero tolerance enforcement policy
All of the above
6. Audit record is vulnerable to
A.
B.
C.
D.
Modification
Disclosure
Deletion
All of the above
© Copyright IBM Corporation 2016
Figure 6-7. Checkpoint
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
6-13
V11.0
Unit 6. Auditing & Logging, Countermeasures
Uempty
Checkpoint
IBM ICE (Innovation Centre for Education)
IBM Power Systems
7. Web server and application server are two different names given to the same entity:
A. True
B. False
8. Common testing methodologies include
A.
B.
C.
D.
Black box testing
White box testing
Grey box testing
All of the above
9. An audit trail should include data about: system-level events, application-level events, user-level
events and:
A.
B.
C.
D.
IT-level events
Encrypted packets
Network connections
Buffer overflows
10. What is considered while selecting countermeasures?
A.
B.
C.
D.
Almost always select the most expensive countermeasures as they provide better security
Cost must equal to the benefit obtained
Cost of the countermeasure should be less than the value of the asset
Technical countermeasures are better than operational ones
© Copyright IBM Corporation 2016
Figure 6-8. Checkpoint
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
6-14
V11.0
Unit 6. Auditing & Logging, Countermeasures
Uempty
Unit summary
IBM ICE (Innovation Centre for Education)
IBM Power Systems
After completing this unit, you should be able to:
• Get an overview of Auditing and logging
• Understand Basic countermeasures to provide security against Web Application Vulnerabilities
© Copyright IBM Corporation 2016
Figure 6-9. Unit summary
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
6-15
V11.0
Unit 7. Lab Exercise - Introduction to Code Analysis using IBM Rational AppScan
Uempty
Unit 7. Lab Exercise - Introduction to
Code Analysis using IBM
Rational AppScan
Overview
This unit provides an insight on code analysis using IBM Rational AppScan
How you will check your progress
• NA
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
7-1
V11.0
Unit 7. Lab Exercise - Introduction to Code Analysis using IBM Rational AppScan
Uempty
Unit objectives
IBM ICE (Innovation Centre for Education)
IBM Power Systems
After completing this unit, you should be able to:
• Gain insight on installation of AppScan
• Understand AppScan functions and running Procedure for downloading the application source code
© Copyright IBM Corporation 2016
Figure 7-1. Unit objectives
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
7-2
V11.0
Unit 7. Lab Exercise - Introduction to Code Analysis using IBM Rational AppScan
Uempty
Installation (1 of 8)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
Double click on ASE_GSCSetup
© Copyright IBM Corporation 2016
Figure 7-2. Installation (1 of 8)
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
7-3
V11.0
Unit 7. Lab Exercise - Introduction to Code Analysis using IBM Rational AppScan
Uempty
Installation (2 of 8)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
Click on run
© Copyright IBM Corporation 2016
Figure 7-3. Installation (2 of 8)
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
7-4
V11.0
Unit 7. Lab Exercise - Introduction to Code Analysis using IBM Rational AppScan
Uempty
Installation (3 of 8)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
On the “InstallShield Wizard” dialogue box
Click on Next
© Copyright IBM Corporation 2016
Figure 7-4. Installation (3 of 8)
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
7-5
V11.0
Unit 7. Lab Exercise - Introduction to Code Analysis using IBM Rational AppScan
Uempty
Installation (4 of 8)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
Select “I accept the terms in the license agreement”
Click on next
© Copyright IBM Corporation 2016
Figure 7-5. Installation (4 of 8)
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
7-6
V11.0
Unit 7. Lab Exercise - Introduction to Code Analysis using IBM Rational AppScan
Uempty
Installation (5 of 8)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
Click on Next
© Copyright IBM Corporation 2016
Figure 7-6. Installation (5 of 8)
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
7-7
V11.0
Unit 7. Lab Exercise - Introduction to Code Analysis using IBM Rational AppScan
Uempty
Installation (6 of 8)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
Click on install.
© Copyright IBM Corporation 2016
Figure 7-7. Installation (6 of 8)
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
7-8
V11.0
Unit 7. Lab Exercise - Introduction to Code Analysis using IBM Rational AppScan
Uempty
Installation (7 of 8)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
Wait for the below shown process to complete
© Copyright IBM Corporation 2016
Figure 7-8. Installation (7 of 8)
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
7-9
V11.0
Unit 7. Lab Exercise - Introduction to Code Analysis using IBM Rational AppScan
Uempty
Installation (8 of 8)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
Click on Finish
© Copyright IBM Corporation 2016
Figure 7-9. Installation (8 of 8)
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
7-10
V11.0
Unit 7. Lab Exercise - Introduction to Code Analysis using IBM Rational AppScan
Uempty
AppScan run procedure
(Web Services Explorer)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
Double click on Web Services Explorer
© Copyright IBM Corporation 2016
Figure 7-10. AppScan run procedure (Web Services Explorer)
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
7-11
V11.0
Unit 7. Lab Exercise - Introduction to Code Analysis using IBM Rational AppScan
Uempty
AppScan run procedure
(Web Services Explorer)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
© Copyright IBM Corporation 2016
Figure 7-11. AppScan run procedure (Web Services Explorer)
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
7-12
V11.0
Unit 7. Lab Exercise - Introduction to Code Analysis using IBM Rational AppScan
Uempty
AppScan run procedure
(Web Services Explorer)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
Click on add an endpoint for HTTP request.
Type Website link in URL Example-http://www.ibm.com/in-en/
© Copyright IBM Corporation 2016
Figure 7-12. AppScan run procedure (Web Services Explorer)
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
7-13
V11.0
Unit 7. Lab Exercise - Introduction to Code Analysis using IBM Rational AppScan
Uempty
AppScan run procedure
(Web Services Explorer)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
Click on Next.
© Copyright IBM Corporation 2016
Figure 7-13. AppScan run procedure (Web Services Explorer)
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
7-14
V11.0
Unit 7. Lab Exercise - Introduction to Code Analysis using IBM Rational AppScan
Uempty
AppScan run procedure
(Web Services Explorer)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
Now click on Finish.
© Copyright IBM Corporation 2016
Figure 7-14. AppScan run procedure (Web Services Explorer)
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
7-15
V11.0
Unit 7. Lab Exercise - Introduction to Code Analysis using IBM Rational AppScan
Uempty
AppScan run procedure
(Web Services Explorer)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
New Dashboard open.
Click on Invoke.
© Copyright IBM Corporation 2016
Figure 7-15. AppScan run procedure (Web Services Explorer)
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
7-16
V11.0
Unit 7. Lab Exercise - Introduction to Code Analysis using IBM Rational AppScan
Uempty
AppScan run procedure
(Web Services Explorer)
IBM ICE (Innovation Centre for Education)
IBM Power Systems
View Responce
© Copyright IBM Corporation 2016
Figure 7-16. AppScan run procedure (Web Services Explorer)
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
7-17
V11.0
Unit 7. Lab Exercise - Introduction to Code Analysis using IBM Rational AppScan
Uempty
Source code
IBM ICE (Innovation Centre for Education)
IBM Power Systems
The website’s source code (AppScan invoke result)
© Copyright IBM Corporation 2016
Figure 7-17. Source code
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
7-18
V11.0
Unit 7. Lab Exercise - Introduction to Code Analysis using IBM Rational AppScan
Uempty
Unit summary
IBM ICE (Innovation Centre for Education)
IBM Power Systems
After completing this unit, you should be able to:
• Gain insight on installation of AppScan
• Understand AppScan functions and running Procedure for downloading the application source code
© Copyright IBM Corporation 2016
Figure 7-18. Unit summary
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
7-19
V11.0
Appendix A. Review answers
AP
Appendix A. Review answers
Unit 1, "Introduction to software development & application security"
Solutions for Figure 1-22, "Checkpoint," on page 1-38
Checkpoint solutions
IBM ICE (Innovation Centre for Education)
IBM Power Systems
1. D
2.
3.
4.
5.
A
A
D
B
6.
7.
8.
9.
A
D
A
A
10.C
© Copyright IBM Corporation 2016
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
A-1
V11.0
Appendix A. Review answers
AP
Unit 2, "Introduction to input validation & sensitive data"
Solutions for Figure 2-31, "Checkpoint," on page 2-49
Checkpoint solutions
IBM ICE (Innovation Centre for Education)
IBM Power Systems
1.
2.
3.
4.
5.
6.
7.
D
A
A
B
C
B
C
8. A
9. D
10. A
© Copyright IBM Corporation 2016
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
A-2
V11.0
Appendix A. Review answers
AP
Unit 3, "Introduction to authentication & authorization"
Solutions for Figure 3-26, "Checkpoint," on page 3-39
Checkpoint solutions
IBM ICE (Innovation Centre for Education)
IBM Power Systems
1.
2.
3.
4.
5.
6.
7.
D
A
D
C
D
B
A
8. D
9. D
10. B
© Copyright IBM Corporation 2016
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
A-3
V11.0
Appendix A. Review answers
AP
Unit 4, "Introduction to configuration management & session management"
Solutions for Figure 4-20, "Checkpoint," on page 4-28
Checkpoint solutions
IBM ICE (Innovation Centre for Education)
IBM Power Systems
1.
2.
3.
4.
5.
6.
7.
D
A
C
D
C
A
D
8. A
9. A
10. C
© Copyright IBM Corporation 2016
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
A-4
V11.0
Appendix A. Review answers
AP
Unit 5, "Introduction to cryptography, parameter manipulation & exception
management"
Solutions for Figure 5-19, "Checkpoint," on page 5-31
Checkpoint Solutions
IBM ICE (Innovation Centre for Education)
IBM Power Systems
1.
2.
3.
4.
5.
6.
7.
C
A
D
A
C
D
B
8. D
9. C
10. C
© Copyright IBM Corporation 2016
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
A-5
V11.0
Appendix A. Review answers
AP
Unit 6, "Auditing & Logging, Countermeasures"
Solutions for Figure 6-8, "Checkpoint," on page 6-14
Checkpoint Solutions
IBM ICE (Innovation Centre for Education)
IBM Power Systems
1.
2.
3.
4.
5.
6.
7.
A
B
A
D
D
D
B
8. D
9. A
10. B
© Copyright IBM Corporation 2016
Unit 7, "Introduction to Code Analysis using IBM Rational AppScan"
No checkpoint solutions in this unit.
© Copyright IBM Corp. 2016
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
A-6