The document provides an overview of web application security principles, focusing on access control, authentication, and authorization. It discusses various authentication methods, including basic and digest access authentication, highlighting their security risks and best practices for securing user credentials. The document also covers the importance of password complexity, the need for secure transmission, and common practices for establishing secure authorization mechanisms in web applications.

1. Introduction to
Web Application Security Principles

2. U – I : Web Application Security Principles
• Web Application (or) Web App :
– Software program stored on a remote server that can be accessed
over the internet through the browser interface.
– Some real time common web apps include :
Google
Docs
Google
maps
Web mail
Online
retail sales
Online
auction
Google
Forms

3. Visit http://demo.horde.org/login.php
• User name : demo Open Source Web App : Horde groupware
• Password : demo
• User name : guest
• Password : guest

4. Access Control
• For some web apps, only certain users are
permitted to access the protected resources.
• eg - 1. Scribd (Only subscribed user can access
the online course materials).
– Subscription (content is available only to the payable
customers) is needed to access the resources.
• eg – 2. New York Times Online Newspaper (as
suggested in text book).

5. Formal Defn of Access Control System
• Access Control System :
– Mechanism that regulates access to data (or) functionality by
determining whether a subject is permitted to perform an operation
on a target object.
– (eg) :
Subjects Operation Target Object Access
Control
Vice
Chancellor
View Data Center Records Permitted
Faculty View Data Center Records Permitted
with some
restrictions
Students View Data Center Records Denied

6. Access Control System
Authentication Authorization
Authentication Authorization
• Proving that you are who
you claim to be.
• Process of determining
whether the validated identity
has the rights to do what they
want to do.

7. Authentication
• Process in which the subject proves that they are whom they claim to
be.
• Authentication is composed of two things :
– Identification and
– Verification (or) Confirmation.
• Authentication is abbreviated as AuthN (or) A1.
• Authorization is abbreviated as AuthZ (or) A2.
• A1 and A2 are referred as Access Control System (level 1
and level 2).

8. • Proving your identity :
Three different factors to prove subject identity includes :
• Something you have
• Something you are and
• Something you know
– Authentication is proceeded based on the combination of above said
factors. (you have + you know) (you know + you are) (you are +
you have)
– Eg’s of the above said factors :
Something you know Something you have Something you are
• Password
• PIN
• Pass Phrase
• Digital Certificate
• Smart card
• Security Token
• Finger Print
• Retinal pattern
• Hand geometry
• Topography of the
face

9. Authentication Types
• Two Factor Authentication :
– ID validation with two factors from any of know/have/are categories.
• Three Factor Authentication :
– A system that requires one from each of the know / have / are categories.
• Web Application Authentication :
– Password Based Authentication Systems :
• HTTP specification provides two built-in authentication systems.
1) Basic Access Authentication
2) Digest Access Authentication
• Single sign-on Solutions
– Windows Live ID
– Facebook ID
• HTTP based authentication is not preferred by security-conscious
web app developers.
The server at request www.auth0.com requires username and
password.

10. Basic Access Authentication
• Form of authentication that requires user to enter a username and
password before accessing a resource on the web server.
• BAA is universally supported by all kinds of web server. Inherently
insecure.
• Process of BAA as follows :
User Web Server
Request for a file www.auth0.com/testing
/employees.html
401 response code Authorization Required
User enters their Authentication
Credentials
Username : Password then base64
encoded with authorization header
If username password mismatches respond
with a 401 error code is returned

11. Issues in Basic Access Authentication
• Insecure Transmission
– Decoding the base64 encoded username : password is trivial for an attacker.
– To secure these user credentials during transmission, they must be submitted
over an SSL connection (or) other encrypted medium.
• Repeated Exposure
– User credentials themselves must be submitted with every single request for
a protected resource.
– In Custom Authentication Systems, web application responds with a session
ID, which is used to identify an authenticated session.
– In Repeated Exposure, the browser caches user credentials and resubmits
them whenever there is an access to a protected resource (Fixed Session ID).

12. • Insecure Storage
– The user name and password must be submitted to the web server
with each request, the browser caches the authentication credentials.
– There is no way to log out, the only way to clear the stored
credentials is to close the tab (or) clear the history.
– To secure the transmission, communication should be done over
SSL.
– SSL mitigates the risk of plaintext transmission and the repeated
exposure of the credentials.

13. Digest Access Authentication
• Similar to the basic authentication scheme except that the MD5 hashing
algorithm is used to transform the password.
• Digest Access Authentication approach uses a “number only used
once” (nonce value) to make replay attacks more difficult.
• What do you mean by nonce ?
– Random number often used in conjunction with authentication
systems to prevent replay attacks.
• Detailed breakdown of the hashing process can be found in RFC2617
– http://tools.ietf.org/html/rfc2617

14. BASIC ACCESS AUTHENTICATION DIGEST ACCESS AUTHENTICATION
https://Aladdin:OpenSesame@www.example
.com/index.html
• In BAA, the user credentials such as {user
name : password} are encoded using base64.
• In DAA, the user credentials are hashed
using MD5 hash function.
• Differences between encoding and
encryption :
• Encoding : Transforms data into another
format using a scheme that is publicly
available so that it can easily be reversed.
• Encrypting : Transforms data into another
format in such a way that only specific
individual(s) can reverse the transformation.
• RFC - 7617.
• BAA (HTTP) when combined with
conjunction in (HTTPS) provides data
confidentiality.
• Number Used Only Once (Nonce) is used
to prevent replay attacks.
• Hash (Client IP : timestamp : private –
key)
• Security Issues :
1) Man-in-the-Middle Attack
2) Replay Attack
3) Spoofing by counterfeit servers
4) Storing Passwords
RFC - 2069

15. Security Risks of Digest AuthN System
• Man in the middle attack :
Attacker
Client Server
Database

16. Single Sign – on (SSO) Authentication
• SSO allows a user to login to a single interface and gain access to
multiple, independently secured systems.
• (eg - 1) : Google Accounts
– By logging to your Google account, the user can access multiple
independent Google services like Gmail, Google Talk, You Tube, etc.,
– Unfortunately, Third party web applications cannot be integrated with this
Google account.
• (eg – 2) : Microsoft’s Live ID Services (HotMail, Xbox Live and
MSN)

17. Custom AuthN Systems
• When a developer has coded their own application logic to process
credentials, is said to be the Custom AuthN Systems.
• Web AuthN Process

18. Web Authentication Process

21. Validating Credentials
• The 4 most common ways of looking up a password that’s being stored in
a database (or) LDAP includes :
– 2 variables are concerned :
• Location of the comparison logic.
• How the password is stored (plain text (or) hashed (or) encrypted).
– Combination of the above 2 variables results in four different
approaches.
1) Comparison Logic in the application with plaintext passwords.
2) Comparison Logic in the database with plaintext passwords.
3) Comparison Logic in the application with hashed passwords.
4) Comparison Logic in the database with hashed passwords.

22. Securing Password based Authentication
• Common security attacks against password includes :
– Dictionary Attack
– Brute – Force Attack
– Precomputed Dictionary Attack and
– Rubber-hose attack
• Online Attacks
– Attempting to guess a password, you can attempt it either against the live
system
• Offline Attacks
– Attempting to guess a password, you can attempt it either against the hashed
or encrypted password values.

26. Dictionary Attack
• Dictionary :
– The most likely candidate words can be collected in a list that is
referred to as a dictionary.
– Real dictionaries can be created by permutations, appending a digit
(or) special character at the end of each word.
– In online situations, it is uncommon for full dictionaries (or)
exhaustive attacks because of the timing limitation.
– In offline attacks, it utilizes multiple dictionaries with several
languages in addition to generating their permutations.

27. • BRUTE FORCE ATTACK
• Referred as Exhaustive key search and in theory involves attempting
every single possible key.
• Limits are usually placed on brute force attack based on length and
character set.
• (eg) : includes alphabet, digits, whitespace, special characters
• PRECOMPUTED DICTIONARY ATTACK
• In this, passwords can be cracked by only looking up the password hash
value in your stored system instead of trying to computing its equivalent
value.
• This method of cracking passwords is called precomputed dictionary
attack.

28. • Popular implementations of this approach include Ophcrack, which
works against windows password, Rainbow crack which works against a
variety of hashing algorithms including LM, MD5, SHA-1.
• Defense against pre computation attack includes SALTING.
• Popular tools to perform dictionary and brute force attacks include John
the Ripper, Hydra, Web Slayer and Cain & Abel.
• Rubber – Hose Attack :
• Refers to instances in which an intruder uses any sort of physical
coercion to extract the value of password from an individual.

29. Importance of Password Complexity
• Goal :
– To create the complex password that leads to tougher “guesses” for an
attacker.
– If key space is larger, the time consumption will be larger to search all the
possibilities.
– Key space :
• Set of all possible passwords
– Size of the key space can be increased by increasing the minimum length
required.
– Regularly changing passwords are more complex.

30. Password Best Practices
• Requires Minimum Password Length
– Smallest number of characters that a password should be composed
of.
– Length of the password contributes more to its security than the
possible characters.
• Enforce minimum password complexity
MINIMUM PASSWORD
LENGTH
STRONG PASSWORD
LENGTH
12 16
CATEGORY CHARACTERS
Uppercase Letters A,B,C,D….,Z
Lowercase Letters a,b,c,…,z
Numbers 1,2,3,..,9
Symbols ( ) ! @ # $ % ^ & *

31. • Rotate Passwords :
– Industry best practice is to rotate the password every 90 days.
– The concept of Rotate passwords is to prevent users from resetting
their passwords several times in one day.
– This leads to No Password Reuse Practice.
• Require Password Uniqueness :
– When a user is rotating their passwords periodically, they should not
be get repeated .
– Usually password history is kept of the recently stored eight
passwords.
• Password cannot be equal to the user name.
• Allow accounts to be disabled. (eg – Facebook account).
• Properly store passwords.
– When storing passwords, strong hashing algorithm with a salt value should
have to be used.
• Don’t store the password as a plaintext (original message).

32. • Don’t encrypt :
– Encrypting a user password using a key imposes two different problems :
• While a password is encrypted using a key, it can also be decrypted by
guessing the key.
• If a key is used, it needs to be protected from attacks.
– Use a strong hash value.
• To perform a one – way transformation on the content.
• The hashed password value is then stored into the database for a specific
user name.
• When the user log into the web application, corresponding username
and password is checked with the database.
• Strong hashing algorithms for passwords includes SHA-256 and SHA-
512.

33. • Use a salt value
– Use a random salt value with each password to increase the security
of the password.
– Reason for using a salt value is two fold :
1. It makes pre-computed dictionary attack much more difficult.
2. If two users uses the same password, it results in the same
computed hash value.
• Salt
– Piece of random data that is added to the input of the hashing
function.
– Salt value + password  To increase the difficulty of the attacks
against the stored passwords.

34. • Multiple Rounds of Hashing
– For each password being stored, hashing function is applied over and
over again.
– The o/p of the first hashing function is the i/p for the second hashing
function that results in increasing the security of stored passwords.
– Standard mechanisms such as (Password Based Key Derivation
Function) PBKDF and PBKDF2 assist in performing the multiple
rounds of iteration.

35. When and Where to perform authentication
• When a user’s access level (or) rights changes.
• With every request to protected data (or) functionality.
• When accessing an outside resource (or) third-party
resource.

36. Secure Web Authentication Mechanisms
• The following are the practices to be followed while designing and evaluating the secure system.
• Secure the transmission (data transmission) using SSL/TLS.
• Allow Account Lockout.
– Account Lockout is based on the following factors :
• How many failed attempts should trigger a lock out ?
• Within What timeframe are we counting failed attempts ?
• How long do we lock out the account until it automatically resets?
• Completely Automated Public Turing Tests To Tell Computers and Humans Apart (CAPTCHA)
• Allow Accounts to be disabled.
• No Default Accounts. (WebAPP with user name “Admin & guest”)
• Don’t Hardcode Credentials.
• Avoid Remember me (Stay Signed In)  Long Cookie expiration with session ID.

37. Authorization
• Granting (or) denying access based on the set of rules.
• Session management go hand in hand with authorization.
• Session Management :
– Both client and server keeps track of who the user is
– Closely related to what the user is allowed to do and
– What the user is actually doing.
• Session and Session Management is also considered as an another
layer of interaction between web browser and web server.
• Authorization Fundamentals
– Process of deciding whether a user can perform a certain action.
– (eg): Joe accessing a health data application hosted by his doctor’s
office.
– Joe has to be authenticated with his username, social security
number, health insurance account number.

38. Simple Model of AuthZ

39. • Health Insurance Portability and Accountability Act (HIPAA).
• Authorization Goals :
– We authorize for the following three reasons :
• To ensure that users can only perform actions within their privilege
level.
• To control access to protected resources using criteria based on a user’s
role (or) privilege level.
• To mitigate Privilege escalation attacks,
– Enable a user to access administrative functions while logged
on as a non-administrative user (or) potentially even an
anonymous guest user.

40. Detailed Authorization Check Process
• In the world of web application, a subject is commonly referred
as,
– An actual human user accessing the web appln.
– Web appln accessing the web service.
– Web service accessing the back end database.
– Back end database accessing their own local operating system.
– Another computer system (or) host.
• Resources
– Resources are encoded in Uniform Resource Locator (URL) parameters.
– Anything after a “?” is a parameter.
– URL :
http://www.MyHometownNewspaper.com/archieves?article=00293859231.
– Accessing a book from an Amazon website .
– Encode the title of the book as an identifying number.

41. • http://www.amazon.com/Domain-Centric-Security/B000SLAKO
• Determining Access
– Policies comes in different styles as well.
– Access Control List (ACL) are permissions that are applied to specific resource.
• Role based Authorization :
– Nobody else can read or write any of my files, except I want Bryan to have
read/write access on files.
• Access Control Models :
– There are three general patterns of Access Control Models you follow :
• Discretionary Access Control (DAC)
• Mandatory Access Control (MAC) and
• Role based Access Control

42. • Discretionary Access Control
– Access Control is left to the discretion of the owner of the resource.
• Mandatory Access Control
– Access Control is determined by the system administrator rather than object
owners.
• Role-Based Access Control
– Non-discretionary model , which implements access controls by means of roles.
• Types of Permissions
– Read access
– Write access and
– Execute access
• Read access
– Read access just means the ability to see what something is, to have it’s contents
presented for user perusal.

43. • Write Access
– General ability to change something.
• Execute Access
– Ability to run a piece of code in order to do something.
• Authorization Layers
– Authorization should happen at many points and many times within a web
application.
• Authorization occurs both in horizontal and vertical directions.
• Horizontally, authorization takes place at the boundaries between systems on
the path from user to application.

44. • Horizontal layers are as follows :
– Web client
– Front-end web server
– Back-end application servers
– Back-end database
• Vertical layers are as follows :
– User Layer
– Application Layer
– Middleware Layer
– Operating System Layer
– Hardware Layer
• Securing Web Application Authorization
– Web Server Layer
• IP Address Blacklisting (“403 Forbidden HTTP response”) to the user
• IP Address Whitelisting (“B2B also known as e-biz” web application”)
• URL Authorization (“Web application allowing access to specific URL’s”)
• Operating System Authorization(“To manage physical and logical resources
exposed by the OS itself”)

45. URL Authorization
• Some web servers and applications framework provide facilities for
limiting access to specific URLs.
• Through various settings (or) configuration files, you can specify which
users and groups can access what URLs.
• Sample configuration File :

46. • Servlet and APPserver Restrictions
• Application Server Code
– Use a built-in framework
– (eg) : Microsoft .NET platform has built-in security modules for role based
security.
– The ASP.NET has a membership framework that is primarily intended for
form-based AuthN.
– Refer the document http://msdn.microsoft.com/en-
us/library/5k850zwb.aspx

47. • Use an existing, open plug-in AuthZ Module
– There are a number of AuthZ modules that plugin to various web development
frameworks which by default not present in the web application.
– (eg) : includes OAuth, BB Auth, AuthSub and others.
– OAuth – Open Authorization (token based authorization) (Twitter Analysis API)
– BBAuth – Browser based Authentication & Authorization
– AuthSub – Google Data API for the user data (or) credentials.
– Check the documentation for web development framework (or) ask around on
community support.
• Develop a custom framework
– Designing and developing a proper authorization framework is a significant
undertaking.
– If at all possible, use an existing framework (or) plug-in module.

48. Code Access Security (CAS)
• CAS is the idea of performing AuthZ on pieces of code themselves.
• CAS is used to determine whether the code is allowed to run with the
capabilities it wishes to use.
• CAS is related to the idea of assessing whether the code is allowed to run with
the capabilities it wishes to use.
• CAS is typically used to prevent uploaded (or) downloaded components from
performing dangerous actions.
• Preventing untrusted code from performing privileged actions.
• CAS evaluates available evidence such as the,
– Code’s origin,
– Its publisher,
– It’s assembly strong name (for .NET)
– It’s Checksum and
– To determine whether the code should be run.

49. Database Server Layer
• Every web application has a back end named “database”.
• Databases such as Microsoft’s SQL Server, Oracle and others have their own
implementation on concepts such as users, roles, permissions, and so forth.
• Wrap every request to create, read, update (or) delete data within properly
parameterized stored procedures.
• Revoke the access permissions from all the tables of the users database.
• It reduces the database’s overall attack surface.
• Map all the interactions between the application and the database user accounts
and reduce the permissions those accounts have to the bare minimum.

50. Where should you put Authorization Logic ?
• Most applications put the code in the web application.
• All “smarts” has been incorporated to determine who can and cannot do
what and then grant the application itself full.
• Stored procedures in a database can contain both business logic and an
application logic.
• The business logic is essentially in the use of a stored procedure to map
between high-level conceptual operations.
• Stored procedure also contains authorization logic.

51. Custom Authorization Mechanisms
• The 3x3 Model of Authorization
– Any authorization framework, whether pre-existing or custom,
should be designed around a three-by-three matrix of factors (also
referred as lattice).
• What :
– The first axis in the 3x3 model matrix is the “what” axis.
– Users/Subjects
• Any entity that’s making a request against a resource.
– Operations
• The functionality resources in your web application.
– Objects
• Resources managed by your web application, the underlying
things such as data, that your web application cares about.

52. • When
– 2nd axis.
– It considers the time when permissions checks need to happen and
approvals granted (or) denied.
– 3x3 Authorization System
– Before loading the interface.
– Before requests are submitted and
– Before granting final access.

54. • Common Attacks
– Client Side Attacks
– Time of Check To Time of Use (TOCTTOU) Exploit
• Web Authorization Best Practices
1. Failing Closed
1. Restart everything in case of failure of anything. (Brutal and
inconvenient policy)
2. Operating with Least Privilege
3. Separating Duties (Regular user and Administrator)
4. Defining Strong Policies.
5. Keeping Accounts Unique
6. Authorizing on Every Request.
7. Centralizing the Authorization Mechanism.
8. Minimizing Custom Authorization Mechanism.
9. Protecting Static resources.
10. Avoiding Insecure Client-Side Authorization Tokens.
11. Using Server Side Authorization
12. Mistrusting Everybody

55. Attacks on Authorization
• Forceful Browsing
• Parameter Tampering
• HTTP Header Manipulation
• Cross-Site Request Forgery
Session Management Fundamentals
• Introduction to Session
• Session State
• Session State Persistent Strategies
• Cookies
• Form Fields and URL query parameters
• Web Storage
• Flash Local Shared Objects (LSO)
• Silver-Light Isolated Storage
• Server Side Storage

56. Attacks Against Session
• Tampering
• Theft
• SSL and HTTPS
• Predictability
• SESSION PREDICTABILITY IN THE REAL WORLD (JETTY)
– Session Fixation
– Session Hijacking
– Side Jacking
– Cross-site Request Forgery
• SESSION MANAGEMENT BEST PRACTICES
– Enforcing absolute session time outs.
– Enforcing idle session time outs.
– Limiting session concurrency.
– Mandating secure cookies.
– Using the HTTP only flag
– Using Random Session ID’s
– Using Encrypted Cookies.

57. Browser Security Principles
• Web browser have controls built into them in order to prevent malicious
web sites from stealing user’s personal data.
• Defining the Same Origin Policy
– Essentially an agreement among browser manufacturers.
• Limit the functionality of scripting code running in user’s web
browser.
• The same-origin policy states that when a user is viewing a web
page in his browser (script running on the web page should be
able to read (or) write the content of another web page if they
have same origin).

58. • Defining the Exceptions to the same origin policy
– To get around the same origin policy with enhanced security as
possible :
• HTML <SCRIPT> ELEMENT
• JSON AND JSONP
• iframes and JavaScript document.domain
• Adobe Flash Player Cross-Domain Policy File
• Microsoft SilverLight
• Ajax and Cross-Origin Resource Sharing
• XDomainRequest

59. Cross-Site Scripting (XSS)
• It is a vulnerability that allows an attacker to add his own script code to a
vulnerable web application pages.
• Root Cause of XSS Vulnerabilities :
– When a web application accepts input from a user and then displays
that input as-is, without validating it (or) encoding it.
–

60. Alert Box

61. Types of XSS
• Reflected XSS (Common variety)
• Local XSS (Flavor of Reflected XSS with the slight twist)
• Stored XSS (Most Dangerous variety)

62. POST based Reflected XSS Type - 1
• Instead of using GET method, create HTML form on that page that will
send a POST request to the destined URL.
• Step – 1 : Create a <form> element
• Step – 2 : Set the HTTP request method (POST)
• Step – 3 : Destination URL.

63. • Stored XSS (Type – 2)
• In this web application echoes back user input without validating (or)
encoding it.
• Local XSS (Type – 0)
• Also called DOM based XSS.
• Many JAVA script functions that can make a web application at risk of
local XSS, pull their arguments from untrusted user input.
• Functions include,
– document.writeln()
– document.createElement()
– document.location()
– element.innerHTML
– eval()
– window.navigate()
– window.open()

64. HTML Injection Attack
• Another variation of attack as of other types of XSS considered as
HTML injection attack.
• Instead of injecting malicious java script, malicious HTML code is
inserted into the application that gives rise to HTML injection Attack.
•

65. Defense Methods of XSS
• Encoding Output
• Sanitizing Input
• Using a Reduced Markup Language
• HttpOnly
• Content Security Policy
• Ineffective CSRF Defense :
– Relying on HTTP POST Method.
– Checking the Referer Header.
– URL Rewriting
• Better CSRF Defense :
– Shared Secrets
– Double-Submitted Cookies
• Preventing XSS :
– Reauthentication
– What being “Logged In” Means

69. Remote File Upload
• Java Script file and HTML file for a specific web application can be
uploaded in the web vulnerability scanner in order to collect the
vulnerability report.
• Vulnerabilities Rating based on the risk
1) XSS
2) SQL Injection
3) File upload
4) Cross Site Request Forgery
5) Local File Inclusion
6) Remote Code Execution
7) Full Path Disclosure
8) Remote File Inclusion
9) Authentication Bypass
10) General Bypass
11) Open Redirect
12) XML External Entity
13) Denial of Service

70. Remote File Upload Vulnerability
• It is an application uses user input to fetch a remote file from a site on an
internet and store it locally.
• The locally stored file is then executed by an attacker.
• Avoiding Remote File Upload Vulnerabilities :
– Only allow specific file extensions.
– Only allow authorized and authenticated users to use the feature.
– Check any file fetched from the Web for content. Make sure it is
actually an image or whatever file type you expect.
– Serve fetched files from your application rather than directly via the web
server.
– Store files in a non-public accessibly directory if you can.
– Write to the file when you store it to include a header that makes it non-
executable.

71. Penetration Testing
• Penetration testing is used to find flaws in the system in order to take
appropriate security measures to protect the data and maintain functionality.
• Used to test the insecurity of an application.
• Security attack is normally an accidental error that occurs while developing
the software.
• (eg) : Configuration Errors, Design Errors and software bugs.
• Why Penetration Testing is Required ?
• It helps to avoid white hat attack, black hat attack.
• It helps to find weak areas where an intruder can attack to gain access to the
computer’s features and data.

72. • When to perform Penetration Testing ?
• To secure the functioning of the system.
• Security system discovers new threats by attackers.
• You add a new network infrastructure.
• You update your system or install new software.
• You relocate your office.
• You set up a new end-user program/policy.

73. Steps of Penetration Testing

74. • Planning and Preparation
– It starts with defining the goals and objectives of the penetration testing.
• The common objectives of penetration testing are :
– To identify the vulnerability and improve the security of the technical
systems.
– Have IT security confirmed by an external third party.
– Increase the security of the organizational/personnel infrastructure.
• Reconnaissance
– Analysis of the preliminary information.
– Objective is to obtain a complete and detailed information of the systems.
• Discovery
– A penetration tester will most likely use the automated tools to scan
target assets for discovering vulnerabilities.
• Network Discovery
• Host Discovery
• Service Interrogation

75. • Analyzing Information and Risks
– Tester analyzes and assesses the information gathered before the test steps for
dynamically penetrating the system. Elements include :
• The defined goals of the penetration test.
• The potential risks to the system.
• The estimated time required for evaluating potential security flaws for
the subsequent active penetration testing.
• Report Preparation
– Report preparation must start with overall testing procedures, followed by an
analysis of vulnerabilities and risks.
– The high risks and critical vulnerabilities must have priorities and then
followed by the lower order.

76. Types of Penetration Testing
• The type of penetration testing normally depends on the scope and the
organizational needs and requirements.
•

77. Black Box Testing White Box Testing Grey Box Testing
• Tester has no idea
about the systems that
he is going to test.
• (eg) :
• a tester only knows
what should be the
expected outcome and
he does not know how
the outcomes arrives.
• Tester has been
provided with whole
range of information
about the systems
and/or network such as
Schema, Source code,
OS details, IP address,
etc.
• It is also known as
structural, glass box,
clear box, and open
box testing.
• Tester usually
provides partial or
limited information
about the internal
details of the program
of a system.

78. Black Box Testing White Box Testing Grey Box Testing
Advantages :
1. Tester need not
necessarily be an expert,
as it does not demand
specific language
knowledge
2. Tester verifies
contradictions in the
actual system and the
specifications
3. Test is generally
conducted with the
perspective of a user,
not the designer
Disadvantages :
1. These kinds of test cases
are difficult to design.
Advantages :
1. It ensures that all
independent paths of a
module have been
exercised.
2. It ensures that all
logical decisions have
been verified along with
their true and false
value.
3. It discovers the
typographical errors and
does syntax checking.
4. It finds the design
errors that may have
occurred because of the
difference between
logical flow of the
program and the actual
execution.
Advantages :
1. The tester does not
require the access of
source code, it is non-
intrusive and unbiased.
2. There is a clear
difference between a
developer and a tester,
so there is least risk of
personal conflict.
3. No need to provide the
internal information
about the program
functions and other
operations

79. Practical Session on WebApp Authentication
• Never Compromise your Identity !!!!
• Visit auth0.com
•