Wednesday, August 19, 2015

High Level Design Documentation Template



Document Revision History


Version
Date
Description
Requested By
Created By
1.0
09/13/2011
High Level design document draft
XYZ Inc
Your Name





































Revision Level
Revision Date
Description of Revision
Revision
Author
1.00
24/09/2012
First Draft



 abc kumar





























Disclaimers
NewLease® is a trademark of XYZ, Inc.
Proprietary and Confidential Information/Copyright Notice. This work contains valuable, proprietary, and confidential information of XYZ, Inc. Disclosure, use, or reproduction outside of International Decision Systems, Inc. is prohibited except as authorized in writing. This unpublished work is protected by the laws of the United States and other countries. The work was created in 2011.
Permitted Uses. This documentation may be reproduced, duplicated, and distributed in electronic and/or printed format by any licensee of XYZ, Inc. or licensee or sub-licensee of an Affiliated Corporation of XYZ, Inc. (collectively "XYZ"), provided, however, that the following conditions are fulfilled:  (i) all copyright and other proprietary notices included in this documentation appear clearly and distinctively on all reproduced, duplicated, and distributed copies; (ii) this documentation is kept in its entirety and without modification or/and alteration; and (iii) this documentation is distributed only to officers, directors, or employees of an XYZlicensee or sub-licensee, or an XYZ licensee or sub-licensee's affiliated corporation. For any other use, authorization must be requested and obtained from XYZ.
Third Party Trademark Acknowledgments. Products and services that are referred to in this documentation may be either trademarks and/or registered trademarks of their respective owners. Neither XYZ, Inc. nor any of its Affiliated Corporations make claim to these trademarks.
Table of Contents
Introduction........................................................................................................ 6
High Level Design Document Overview.................................................................... 6
Audience........................................................................................................... 6
HDD (High Level Design document) Update Policy...................................................... 6
HDD.1      Availability Trigger Process Overview...................................................... 7
1.1         Availability Trigger Process Overview & Scope of the work................................ 7
HDD.2      Availability Trigger Design Details............................................................ 8
2.1         Windows Service Trigger............................................................................ 8
2.1.1     Fetch the Active Facility Data & Form the request....................................... 8
2.1.2     Actuate the existing web service & Transform the Response......................... 8
2.1.3     Database Insertion................................................................................ 8
2.2         Database Objects...................................................................................... 9

High Level Design Document Overview


This business has an approval rate between 30-50% and as such the goal of the scorecard is to allow the SFSI Credit team to make the quickest, most accurate credit decision possible on the non-Financial Statement transactions.  These are transactions which are under $250K or $350K in exposure (based on business line).  SFSI on the whole gains from an operational and cost perspective when they can make the quickest, lowest touch decision on whether to extend credit to these applicants.

Conceptually, the process overview is as follows

This document will cover the high level technical solution to create a custom web service to achieve the scorecard functionality being requested by XYZ inc.

·         The scorecard must provide a recommended decision on each application that falls into one of three categories:  Recommended Approval, Recommended Decline, Manual Review.
·         Any exposure amounts above the business line thresholds (aka Financial Statement transactions) will automatically qualify for “Manual Review” status. We would like the transaction to still go through the rate card.
·         Any transactions not meeting the Credit Filters recommended decision of “Recommended Approval” or “Recommended Decline” will automatically qualify for the “Manual Review” recommendation. With “recommend decline” can data that caused recommendation be highlighted in some fashion?

In Scope

Not In Scope

Flow Charts


Need
Comments
Internal test environment details:
NA
Customer test environment details (DEV/UAT):
These three interfaces should be setup on the following internal server:
-       Database server:
-       Database Name :
-       App and Web server:
-       On the application server, XYZ URL:

Note: XYZ will share later.

Test account credentials for bureau interfaces:
Details have been provided for configuring bureau test environment connectivity in the prior “Bureau Connectivity Details” section.

Prod account credentials for bureau interfaces:
This information has been requested from XYZ along with test accounts for their own use.
All deliverables are SMART: specific, measurable, achievable, realistic, and time-oriented.

Owner
Acceptance Criteria
Due Date
Reviewer/ Approver
An interface to be able to successfully pull a D&B BIR report.
Consultant
 users will review and accept

Lead/Tech Consultant
Ability to successfully pull a PayNet Direct report.
Consultant
users will review and accept

Lead/Tech Consultant
Ability to successfully pull an Experian Personal Credit Report
Consultant
 users will review and accept

Lead/Tech Consultant

Sunday, August 9, 2015

Fundamentals of Application Security

Module Objectives

  • Understand the importance of software security.
  • Understand the cost of security defects.
  • Understand threat and risk management terminology.
  • Distinguish between types of attackers and their motivations.
What is security?


Information security seeks to protect the confidentiality, integrity, and availability of protected information and systems. These three principles of information security are called the CIA triad. Confidentiality means that private or proprietary information is protected from unauthorized disclosure.
Integrity refers to the need to protect information from being modified or deleted by unauthorized users.
Maintaining availability of protected systems ensures that information and business functions will be reliably accessible.

-----------------------------------


Software security is the design and implementation of application functionality intended to ensure the confidentiality, integrity, and availability of protected information and systems.

Software security must align with:
  • Confidentiality
  • Integrity

Software security is not the same as network security. Network security focuses on restricting communication paths between systems. Software security focuses on the run-time logic within applications and the processing of data passed inside of an allowed communication path.

-----------------------------------


Defining Threat Terminology

An asset is a valuable resource, such as customer information or financial data that needs to be protected. Assets vary depending on the perspective of an organization. When classifying assets, it’s important to think in terms of what you want protected as well as what an attacker may be interested in.

A threat is an undesired event that has the potential to cause harm. It may compromise an asset or produce an undesirable outcome. A threat may or may not be malicious.

A vulnerability is a weakness in a system or in a security control that could be used to exploit and cause harm to an asset.


An attack is a malicious action performed on the organization’s confidential information and assets, utilizing one or more vulnerabilities to realize a threat.

A countermeasure is an action devised to address the vulnerability of a system. A countermeasure directly addresses the factors that contribute to a threat, such as improving design, implementation, or deployment.

A security control is a process or a policy put into place to reduce threats to an acceptable level.

---------------------------------

Threats can be categorized based on the types and goals of the attacks. STRIDE is a threat modeling system developed by Microsoft to classify computer security threats. 

STRIDE stands for:
  • Spoofing
  • Tampering
  • Repudiation
  • Information Disclosure
  • Denial of Service
  • Elevation of Privilege
Spoofing is attempting to gain access to a system by using a false identity. This can be accomplished using stolen user credentials or impersonating a host on a network. After the attacker successfully gains access as a legitimate user or host, security controls are not able to distinguish the attacker from the valid entity and the attacker assumes all of the rights and privileges of their target.

Tampering is the unauthorized modification of data, for example, as it flows over a network between two computers or as it is stored in a database.

Repudiation is the ability of users (legitimate or otherwise) to deny that they performed specific actions or transactions. Without adequate auditing, repudiation attacks are difficult to prove.

Information disclosure is the unwanted exposure of private data. For example, a user views the contents of a table or file he or she is not authorized to open, or monitors data passed in plaintext over a network. Some examples of information disclosure vulnerabilities include the use of hidden form fields, comments embedded in Web pages that contain database connection strings and connection details, and weak exception handling that can lead to internal system level details being revealed to the client. Any of this information can be very useful to the attacker.

Denial of service is the process of making a system or application unavailable. For example, a denial of service attack might be accomplished by bombarding a server with requests to consume all available system resources or by passing it malformed input data that can crash an application process.

Elevation of privilege occurs when a user with limited privileges assumes the identity of a privileged user to gain privileged access to an application. For example, an attacker with limited privileges might elevate his or her privilege level to compromise and take control of a highly privileged and trusted process or account.

---------------------------------------------------

Client-side Security

Do not rely on client-side validation for security purposes. All security validation should be done on the server, while client-side checks should be added only to improve usability. For instance, you may check the format of a credit card number on the client, in order to inform the user if they’ve made a mistake and then validate the same input for security attacks on the server. Any input the client sends from their machine can be read, written to, and edited before they are sent to your server. Client-side security controls can be reverse-engineered and manipulated. 

Therefore, any client-side data should be viewed with the consideration that it can and will be overridden by an attacker.

------------------------------------------------

Security Tools

Static Analysis Tools

Static analysis techniques are a powerful way of leveraging automation to identify software security flaws. It is important to incorporate thorough efficient and consistent testing techniques as part of your SDLC.

Static analysis scans the source code or the compiled binaries of your application looking for implementation flaws including Buffer Overruns, Dangerous Functions, DACL problems, Encoding Problems, Exception Handling, Format String problems, General input validation, ignored return values, memory leaks, Package inspection, SQL injection, unchecked values used for buffer access, and unchecked values for memory allocation.

As with all applied perspectives, static analysis has its strengths and weaknesses. By modeling and analyzing software from the “inside”—by looking at the code itself—static analysis is able to understand the complete inner workings of an application. All of the control and data flow logic can be followed in an attempt to identify implementation flaws.

Static analysis, however, cannot detect fundamental design flaws or the complete lack of a security control. Similarly, authorization flaws can represent significant risk within an application, but an automated tool will not have the appropriate business context to determine if such a flaw exists.

No single analysis technique is sufficient to ensure that a piece of developed software is completely free of security vulnerabilities. A robust risk-management program will incorporate multiple analysis technique in a complementary manner.

Dynamic Analysis tools are used while the application is running, and this allows you to observe what the application is doing in real time. They help discover bugs and vulnerabilities that can only happen during runtime. However, they're often difficult to use and, like Static Analysis Tools, cannot find business logic problems.

Application vulnerability scanners scan Web applications for possible buffer overflows, SQL injection, XSS bugs, and related issues. Their limitation is that they need to be able to know what to send, when to send it, how to send it, and figure out what correct and vulnerability-indicating responses are. For instance, if a Web application is vulnerable to a SQL injection attack but does not return anything out of the ordinary for the scanner to detect, the bug will go undiscovered. Similar to static analysis tools, application vulnerability scanners will return a large number of false positives that requires a skilled engineer to filter and sort through.

-------------------------------------------------

OWASP - Open Web Application Security Project (OWASP) is an open-source application security project. This module will help you understand what OWASP is all about.

After completing this module you will be able to:
  • Understand OWASP and its importance.
  • Name each of the OWASP top 10 vulnerabilities.
  • Understand the basics of the vulnerabilities and their impact.
Introduction to OWASP

Open Web Application Security Project (OWASP)

OWASP was founded in 2003 and focuses on improving the security of Web application software.

OWASP is an open-source Web application security project. Members of this project include a variety of security experts from around the world who have shared their expertise to produce a list of the most critical Web application security flaws.

OWASP Top 10 is a document created for Web application security, which highlights the 10 most important Web application vulnerabilities.

Note: The official OWASP Web site is www.owasp.org.

Let’s understand the top10 security flaws listed under the OWASP Top 10 in brief.

1. Injection:

Injection, such as an SQL injection, are security flaws common to Web applications. These flaws occur when user-supplied data is sent to an interpreter as part of a command or a query. In this situation, the attacker’s hostile data tricks the interpreter into executing unintended commands or changing data.

2. XSS (Cross Site Scripting)

Cross-site scripting (XSS) is a computer security vulnerability typically found in Web applications. It occurs when an application takes the data entered by users and transfers it to a Web browser without proper validation or encoding. This allows attackers to execute script in the victim’s browser, which can hijack user sessions, deface Web sites, and possibly introduce worms.

3. Broken Authentication and Session Management

Often, applications fail to protect account credentials and session tokens properly. In such situations, attackers compromise passwords, keys, or authentication tokens to assume other users' identities to their advantage.

4. Insecure Direct Object Reference

A direct object reference occurs when the developer exposes a reference to an internal implementation object, such as a file, a directory, a database record, or a key, as a URL or a form parameter in the software being developed. Attackers can manipulate such references to access other objects without authorization.

5. Cross-site Request Forgery (CSRF)

The Cross-site Request Forgery (CSRF) attack forces a logged-on victim’s browser to send a pre-authenticated request to a vulnerable Web application, which then forces the victim’s browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the Web application it attacks.

6. Security Misconfiguration

After you deploy your Web application online, it undoubtedly will encounter a number of attacks. To prevent these attacks from being successful, you need to follow sound operational practices related to security.
Inadequate operational practices can lead to exploits of security features or of known vulnerabilities. Improper permissions may allow malicious users to perform actions that they shouldn’t.

7. Insecure Cyrptographic Storage

Web applications rarely use cryptographic functions properly to protect data and credentials. So attackers use weakly protected data to conduct identity theft and other crimes, such as credit card frauds.

8. Failure to Restrict URL Access

Frequently, an application only protects sensitive information by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly.

9. Insufficient Transport Layer Protection

Insufficient transport layer protection occurs when SSL or another transport layer security protocol is not used to encrypt vulnerable data. You should always use SSL to protect a session ID or an authentication token in an authentication system.

10. Unvalidated Redirects and Fowards

Unvalidated forwards can allow a malicious user to spoof your site. The malicious user provides the victim with what looks like a link to your site but actually redirects the victim to a malicious location. Many authentication systems use redirection to return a requester to an authorized URL after login, so the user may not notice that the site is incorrect.
To protect an application against unvalidated redirects and forwards, you need to validate the input as well as the referrer header, which can be controlled or manipulated by a malicious user.


Key Concepts of SQL Injection

SQL injection is a software vulnerability that occurs when data entered by users is sent to the SQL interpreter as a part of an SQL query.

SQL injection exploits security vulnerabilities at the database layer. By exploiting the SQL injection flaw, attackers can create, read, modify, or delete sensitive data.

Attackers provide specially crafted input data to the SQL interpreter and trick the interpreter to execute unintended commands.

Let’s look at the SQL example given below. You will notice that user input is required to run this query. The interpreter will execute the command based on the inputs received for the username and password fields.

string SQLQuery = "Select Username, Password FROM users WHERE Username='” + username + "' AND Password = '" + Password + "'";

If an attacker provides ‘or 0=0’ as the username and password, then the query will be constructed as:

String SQLQuery =”SELECT Username, Password FROM users WHERE Username=” or 0=0” AND Password=” or 0=0”;

Since under all circumstances zero will be equal to zero, the query will return all records in the database. In this way, an unauthorized user will be able to view sensitive information.

Preventing SQL Injection

SQL injection can be prevented if you adopt an input validation technique in which user input is authenticated against a set of defined rules for length, type, and syntax and also against business rules. 
You should ensure that users with the permission to access the database have the least privileges. Additionally, do not use system administrator accounts like “sa” for Web applications. Also, you should always make sure that a database user is created only for a specific application and this user is not able to access other applications. Another preventive measure is to remove all stored procedures that are not in use.

Use strongly typed parameterized query APIs with placeholder substitution markers, even when calling stored procedures
Show care when using stored procedures since they are generally safe from SQL injection. However, be careful as they can be injectable (such as via the use of exec() or concatenating arguments within the stored procedure).

Key Concepts of Cross-site scripting (XSS)

Key Concepts of Cross-site scripting (XSS)
  • XSS is a Web-based attack performed on vulnerable Web applications.
  • In XSS attacks, the victim is the user and not the application.
  • In XSS attacks, malicious content is delivered to users using JavaScript.
The 3 type of XSS vulnerabilities are:
  • Persistent
  • Reflective (non-persistent)
  • DOM-based
As the name suggests, Cross-site scripting (XSS) is a Web-based security vulnerability in which a user instead of a Web application is attacked. During such an attack, a vulnerable Web application is exploited to deliver malicious content to users via script. This content can include HTML or JavaScript code and appear as a persistent, a reflective or non-persistent, or a DOM-based attack.

Impact of XSS

By exploiting XSS vulnerabilities, an attacker can perform malicious actions, such as:
  • Hijack an account
  • Spread Web worms
  • Access browser history and clipboard contents
  • Control the browser remotely
  • Scan and exploit intranet appliances and applications
Note: In an attack exploiting XSS vulnerabilities, anything that can be scripted, can be used to attack a user.

Identifying XSS Flaws

XSS vulnerabilities may occur if:
  • Input coming into Web applications is not validated.
  • Output to the browser is not HTML encoded.

XSS allows an attacker to embed malicious script to be run by an unsuspecting browser, using:
  • JavaScript
  • VB Script
  • ActiveX
  • HTML
  • Flash
Be suspicious any time user-provided input is echoed to the page, such as from:
  • Form input
  • Reverse DNS lookup
  • Hidden tags
An XSS flaw is likely to occur if the input data coming into Web servers is not validated at the source or if data output to the user is not HTML encoded.
When incoming data isn’t validated, XSS flaw allows attackers to embed malicious script that can be executed on an unsuspicious Web browser using JavaScript, VB Script, ActiveX, HTML, or Flash. 
HTML encoding the output to the user will make sure any script is rendered as text and not executed by the browser.
Additionally, you should be suspicious any time user-provided input is echoed on the page. This applies to input such as form input, reverse DNS lookup, and hidden tags.

Preventing XSS Flaws

In order to avoid the XSS vulnerabilities, you can perform the following actions:
  • URLEncode all user input returned as part of URLs (convert ?, &, /, <, >, and spaces to their respective URL encoded equals).
  • HTMLEncode all user input returned as part of HTML.
  • Convert all user input to a single character encoding before parsing.
To prevent XSS vulnerabilities, you should URLEncode all user input that is returned as part of URLs. This will convert ?, &, /, <, >, and spaces to their respective URL encoded equals. Additionally, you should HTMLEncode all user input returned as part of HTML. This will also convert special characters into their respective HTML encoded equals. Last but not the least, you should convert all user input to a single character encoding before parsing. This applies to Single/Double Hex Encoding, Unicode Encoding, and UTF-8 Parsing.

Attacker convinces the victim to send request to server with attacker's input. - Reflected XSS
Client side script doesn't adequately defend against malicious input. - DOM Based XSS
Attacker submits input to server - Persistent XSS

Session Hijacking

Session hijacking is the alteration of session data to impersonate the session data of another user, taking over the user’s session. Session hijacking can be done in several ways:
  • Attacker intercepts the communication between the client and server and steals a valid session ID.
  • Attacker tries to steal session information from the cookies stored in the user’s computer.
  • Guess a predictable session ID.
The Web is inherently connectionless and stateless and developers rely on data sent to the client and returned with each new request to track the user’s session. Improper handling of such information can lead to an attack where an attacker alters session data and impersonates the session data of another user, hijacking the user’s session.

After attackers know where this information is stored, they simply alter the information in such a way that the server will view it as the valid session of another user whose session is hijacked.

Session hijacking can be done in several ways. For example, an attacker can intercept the communication between a client and a server and steals a valid session ID. Alternatively, an attacker can try to steal session information from the cookies stored on the user’s computer. 
Finally, if session IDs are predictable an attacker could guess a valid one.

Preventing Session Hijacking

In order to prevent or mitigate Session hijacking:
  • Use secure random session IDs such as JSESSIONID.
  • Bind the session ID to another piece of identifying information, e.g. user’s IP address.
  • Expire sessions on logout and after a set period of inactivity.
To develop a secure application, you should restrict the instances of session hijacking by following some simple guidelines.

Most Web frameworks provide us with secure random session IDs such as JSESSION ID. You need to ensure that all other session data should be stored on the server side and referenced with this JSESSION ID. Using a secure random ID will make guessing difficult for an attacker and will not be able to guess another valid session ID.

An application developer should also bind the session ID to some other piece of identifying information, such as the IP address of the user. This will make it more difficult for an attacker to use a stolen, valid session ID.
An application developer should also bind the session ID to some other piece of identifying information, such as the IP address of the user. This will make it more difficult for an attacker to use a stolen, valid session ID.

As soon as a user logs out of a session, the session should expire. The session should also expire after a set period of inactivity. This ensures that an attacker will not be able to replay a valid session at a later stage.

Example of Session Fixation

Let’s observe an example where an attacker induces a client to establish a session with the target software using a session identifier provided by the attacker.

Analysis indicates that the attacker either has used a malicious link or has leveraged on an earlier attack, such as XSS. 

As soon as user requests for a specified application with a valid session ID, the application authenticates the user. However, the attacker already knows the same session ID. Therefore, the attacker will now be able to use the session identifier for their own transactions. 

So what does this imply? The attack leverages the fact that the target software either relies on client-generated session identifiers or maintains the same session identifiers after privilege elevation. 

How to prevent such instances? To prevent session hijacking it is important to invalidate the unprivileged session ID and provide a new session ID after authentication. It is also important to ensure correct logout, password management, and timeout functions to help mitigate various instances of session fixation and hijacking.

Key Concepts of Insecure Direct Object Reference

Insecure Direct Object Reference is a security vulnerability that occurs when a developer accidentally or due to negligence happens to create a URL or form parameter exposed to the user with a reference to an object, such as a file, directory, database record, or a key, which is confidential to the organization. 

Due to such an exposure, attackers can easily manipulate the reference and gain access to other confidential objects and view or modify them. 

The best protection is to avoid exposing direct object references to users by using an index, indirect reference map, or another indirect method that is easy to validate. If a direct object reference must be used, ensure that the user is authorized before using it.

Directory Traversals

Challenge: Request a filename from user

Problem: User may input correct filename…

OR…

May attempt to escape Application Directory by:
  • using “/” or “\” to access root directory
  • using “..” to access parent directory
  • manipulating symbolic links (i.e. shortcuts)
Addressing Directory Traversal Issues

In order to prevent or mitigate directory traversal:
  • Examine code against a user-specified file
  • Always use Explicit paths
  • Define application-specific MYAPP_PATH
  • Use regular expressions to opt in known good paths
For example:

^[cd]:(?:\\\w+)+\\\w{1,32}\.(txt|jpg|gif)

To avoid directory traversal, you should examine application code against a user-specified file. You should avoid relative or default paths. In addition, you should never use the environment variable path for locating files because they can be changed and cannot be relied upon. Therefore, you should always define explicit, application-specific paths, such as MYAPP_PATH. To do this, you can use a regular expression that will allow you to use the files present on paths already known, verified, and secured by you. Note the sample expression displayed on the screen. In this expression, the displayed path is alphanumeric, which allows the application to accept txt, jpg, or gif files from the C or the D drive of the server hosting the application.


Key Concepts of Cross-Site Request Forgery (CSRF)

CSRF is a malicious attack where the attacker exploits the user’s Web browser to execute undesired actions on behalf of the user. These actions include:
  • Transferring funds
  • Changing passwords
  • Purchasing items using online shopping
Cross-Site Request Forgery (CSRF) is a malicious attack that tricks the user’s Web browser to perform undesired actions so that they appear as if an authorized user is performing those actions. 
For example, if an attacker is able to modify the content viewed by a user’s browser, perhaps with a hostile Web site, when the user is checking an online bank account, the attacker can change the user’s transaction password to control the user’s actions and transfer funds to the attacker’s account.

Executing CSRF Attacks

CSRF attackers use the functionalities of the victim’s browser against them.

When a user accesses a Web site and logs on to his account, the user’s credentials are stored within the Web site’s cookie.

The Web browser automatically associates the cookie with the actions the user performs on the Web site.

Since the user was authenticated by the Web site, if an attacker exploits the CSRF vulnerability at this stage, the Web application is not able to distinguish between a valid action performed by the user or a malicious action initiated by an attacker.

Example of CSRF

Consider that Big Safe bank has launched a new URL to enable users to transfer funds online. An attacker is closely monitoring the services the bank has to offer.

Soon after the URL launch, the attacker is waiting for an opportunity when a user will click the URL to transfer funds. The attacker has plans to exploit the CSRF vulnerability.

However, when the user does not access the link, the attacker plots a trick against the user. The attacker sends out an e-mail message and includes a malicious tag in the e-mail message. When the user receives the e-mail, the user tries to click on the link, but sees an error message on the screen saying the page cannot be displayed. However, by then the attacker has gained control over the user’s browser and is transferring funds from the user’s account.

Preventing CSRF

The most common defense is to append challenge tokens to each request. These challenge tokens must be associated with the user’s session.

Advantages of using challenge tokens are:
  • Attackers will not be able to provide a valid token of their own to utilize within the attack.
  • Developers can ensure that the request is valid and not coming from a source other than the user.
The most common method to prevent CSRF attacks is to append challenge tokens to each request and associate them with the user’s session. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from another source other than the user.

Security Misconfiguration

After you deploy your Web application online, it undoubtedly will encounter a number of attacks. To prevent these attacks from being successful, you need to follow sound operational practices related to security.

Inadequate operational practices can lead to security compromises using exploits of security features or of known vulnerabilities. Improper permissions may allow malicious users to perform actions they shouldn’t.

Misconfiguration Types

Missing patches
Patches, hotfixes, service packs, and updates contain the latest security fixes and need to be applied when they are available.

Misconfigured or disabled security features
If a security feature is disabled or not configured, it cannot provide protection.

Default accounts
Default accounts may allow a malicious user to automatically login with the credentials published in product documentation.

Unnecessary/unused services or features
These represent an increased risk for security problems. Bugs exist even in the best-written code, By disabling or removing unused and unnecessary services, code, and libraries, you limit the amount of code that needs to be maintained and patched. When in doubt, turn features off, and turn them back on only if you need them. Of course, verify all changes and removals before putting them in production.

Administrative back doors
Administrative back doors are known as front doors in the hacking community. It’s absolutely critical to secure these administrative endpoints given what they are: the keys to the kingdom. Do not rely on a malicious user overlooking the functionality; it can always be discovered. Security through obscurity is no security at all.

Parts of the Stack Vulnerable to Misconfiguration
  • OS
  • Environment/Platform
  • Web or Application Server
  • Database Server
  • Application(s)
  • Components and Libraries
  • Services

Security Misconfiguration: Dynamic Threat Environment

The online world is a dynamic environment where threats develop and manifest every single day. To mitigate and maintain a secure environment, you need a process that can quickly adapt to these threats. A repeatable process is required to constantly reevaluate the environment and address new or growing threats, and should include the following:

  • Updating the environment: This includes changes like adding or removing network segments, and changing configuration.
  • New products: New products or functionality may be needed to deal with a threat that did not exist when the application was released.
  • Service packs and patches: Use a regular process to apply the latest service packs, patches, hotfixes, and updates to all of your software, from top to bottom.

In addition, your development, test, and staging environments should precisely match the production environment. If your environments don’t match, you might discover on release day that your application doesn’t work as expected.

For example, a Nasdaq breach in February of 2011, after investigation by FBI and the secret service, was narrowed down to unpatched Windows systems and poor firewall configurations. While the core trading systems most likely remained intact, it could not be determined how much proprietary and client information was stolen. Unpatched systems could have been prevented by Nasdaq avoiding downtime as a result of investigations, loss of revenue and loss of customer trust. Especially in this tough competitive market, there is no reason to be faced with the same issues as Nasdaq.

GlobalSign, a leading digital certificate provider, was also breached late in 2011 as a result of an unpatched piece of open source software. Although fortunately the company’s root certificate that is used to sign other digital certificates was not compromised, GlobalSign had to halt certificate issuance for 9 days, face additional audits and most importantly lost its public trust due to the breach.

GlobalSign states that the particular open source code was not on the list of software to be updated. It is important to keep an accurate inventory of all systems and software they run. You cannot protect what you don’t know you have.

Mitigating Security Misconfiguration: Repeatable Hardening

A well-defined process provides your first line of protection against a dynamic threat environment. A regular, repeatable hardening process is required to make sure your environment is protected against the latest threats.

Keep the following in mind as you create and implement your process:
Research all stack components for potential vulnerabilities
               –   Vendor/project sites
                         •   http://www.symantec.com/security_response/ Symantec 
                             Security Response Summarizes the current state of active 
                             threats and vulnerabilities in popular software
                         •   http://nvd.nist.gov/ National Vulnerability Database is a 
                             comprehensive list of vulnerabilities
               –   Security sites
                         •   http://www.securityfocus.com/ Site with security news and 
                             vulnerabilities. They also host the popular BugTraq mailing 
                             list
                         •   http://www.us-cert.gov US Government Site focused on 
                             improving the nation’s cyber-security infrastructure
                         •   http://www.securitywizardry.com/radar.htm A nice graphical 
                             summary screen of the current state of cyber-threat activity
               –   Security mailing lists/aliases
                         •   BugTraq – While it can be a chatty list, it provides insite on 
                             hot of the press discovered vulnerabilities.CISSPForum – 
                             For Security professionals discusses current issues 
                             effecting the state of cyber Security
               –   Search for any additional information
Review all settings and configurations
               –   Pay close attention to security features
               –   Look for standard recommendations for secure configurations of 
                    your platforms and applications from their vendors, standards 
                    organizations, and security organizations
Review all enabled features
               –   Disable any unnecessary features
Repeat the process:
               –   At regular intervals; monthly, bimonthly
               –   Every time a deployment or configuration changes 

Insecure Cryptographic Storage

Another common vulnerability occurs when sensitive data is not stored securely from internal users. Often, it is assumed that data storage will not be examined by an arbitrary user. But many users within the organization have access to the registry, temporary files, and databases. It’s possible for these users to access sensitive data in its unencrypted format using temporary, hidden, and registry files. It is also possible for an attacker to gain access using another one of the OWASP Top 10 vulnerabilities such as Direct Object Access.

So, to ensure security, begin by identifying all sensitive data and encrypt that data even when it’s stored on a hard drive. Ensure that sensitive data cannot be easily overwritten and overwrite sensitive memory locations immediately. Then, identify the people who should and shouldn’t have knowledge of secrets such as proprietary algorithms, encryption keys, and DRM. In most cases, it’s recommended to hide these secrets from even the administrator. Additionally, identify all sensitive data read into the memory and overwrite it with random data.

Poorly Implemented Cryptography

When used properly, cryptography is an effective way of protecting data. However, it is very easy to use cryptographic packages incorrectly, which keeps data unprotected and vulnerable to attackers.

Often, developers use either inappropriate ciphers or weak algorithms such as MD5, SHA-1, and RC3 to encrypt data. This enables malicious users to easily decipher encrypted data and access it. Another common issue is the predictability of “random” seed data for encryption and poor key management.

Since cryptographic routines are mathematically proven, its keys are literally the ‘keys to the castle’—the weakest point in the defense.

The common key management cryptography errors include hard coding key values anywhere in the source, including resource files, failure to protect key data in memory or when persisted to file, generating the key from data that is not random enough, and using key data too often in your application. Using key data frequently provides more chances for attackers to steal it.

Poorly Implemented Cryptography: Example

private byte[] encrypt(byte[] plain, byte[] key)
{
     for(int i=0; i< plain.Length;i++)
     {
             plain[i] ^= key[i % key.Length];
            return plain;
      }
}

Consider this algorithm as an example. It only uses XOR on the plaintext with the key. This obscures the text but provides little or no security to the data. To use cryptography appropriately, use CryptKeyGen. It helps create robust keys and makes the key generation process easier. You can also use FIPS 140-1 (Federal Information Processing Standard) 140-1 because it provides a standard implementation of several widely used crypto algorithms and it judges to ensure that they meet a minimum standard.

Failure to Restrict URL Access

If your application fails to appropriately restrict URL access, security can be compromised through a technique called forced browsing. Forced browsing can be a very serious problem if an attacker tries to gather sensitive data through a Web browser by requesting specific pages, or data files.

Using this technique, an attacker can bypass Web site security by accessing files directly instead of following links. This enables the attacker to access data source files directly instead of using the Web application. The attacker can then guess the names of backup files that contain sensitive information locate and read source code or other information left on the server, and bypass the “order” of Web pages.

Preventing Forced Browsing

To prevent forced browsing, you can use appropriate permissions or ACLs to disallow anonymous reading. Do not allow the anonymous Web access user read permissions to any sensitive data files.

Secondly, define the list of file types available for remote reading on the server. Many servers allow you to define which file extensions can be served remotely. For example, .log, .dat, and database files are not files that all users should have access to—except through secure channels.

Also, remove all unnecessary files from Web accessible directories. That is, if files are unneeded within the directory, remove them, even though they may be secure. ACLs may need to change in the future, and this could pose a security risk.

Finally, use virtual directories for Web access and separate secure directories data. They allow you to specify granular ACLs and can help in directory traversal bugs.

Insufficient Transport Layer Protection

Applications often transmit sensitive data across networks and intermediate application nodes. It’s possible that sensitive data is leaked to an eavesdropper during such transmissions. To ensure that sensitive data in transit isn’t compromised and modified by malicious users, the channel between communication end points should be secured.

There are two aspects for ensuring secure connections—privacy and integrity. Privacy ensures that data remains confidential while in transit and is usually enabled using encryption. Integrity ensures that data is protected from accidental or deliberate modification while in transit.

There are two technologies available to ensure secure communication—Secure Sockets Layer / Transport Layer Security (SSL/TLS) and Internet Protocol Security (IPSec).


Secure Sockets Layer and Transport Layer Security (SSL and TLS)

SSL/TLS is commonly used to secure the channel between a browser and a Web server. It is application independent and allows protocols like HTTP, FTP, and Telnet to be layered transparently on top of it. 

SSL supports a variety of cryptographic algorithms. For example, during the "handshaking" process, it uses the RSA public-key cryptosystem, and after the keys are exchanged, it uses a number of ciphers including RC2, RC4, IDEA, DES, and triple-DES.

Internet Protocol Security (IPSec)

IPSec provides a transport level secure communication solution that can be used to secure the data sent between two computers.
  • It is mostly used in Virtual Private Networks (VPNs).
  • It ensures confidentiality and authentication of all network traffic at the IP level.
Other features of IPSec are as follows:
  • It can provide some security services in the background with no impact on user or the developer.
  • It does not provide user-level authentication.
  • It uses the philosophy that only the OS configuration needs to change and not individual applications.
Unvalidated Redirects and Forwards

Unvalidated forwards can allow a malicious user to spoof your site. The malicious user provides the victim with what looks like a link to your site but actually redirects the victim to a malicious location. Many authentication systems use redirection to return a requester to an authorized URL after login, so the user may not notice that the site is incorrect.

To protect an application against unvalidated redirects and forwards, you need to validate the input as well as the referrer header, which can be controlled or manipulated by a malicious user.

Results

Unvalidated redirects and forwards can result in the following consequences:
Complete spoof of your site. A phishing attack could redirect the client to a malicious Web site. A malicious user can also use redirects in combination with a CSRF attack. For example, if the vulnerable action checks the referrer to validate that it comes from your vulnerable site, the unvalidated forward makes the mitigation insufficient.
Bypassed authorization checks. In most common Web platforms, an API call exists that directly transfers a client to another location, bypassing authorization checks. If such an API is used to implement an unvalidated redirector, a malicious user simply needs to use the redirect as the entry point to all other resources on the site.

Mitigating Unvalidated Redirects and Forwards

To mitigate unvalidated redirects and forwards, use the following guidelines:

  • Never use internal transfer without authorizing the user for the target URL. In general, it is far easier to use a redirect method, which will issue a 302 response to the client and ask the client to make another request for the target URL. At that point, it will be like any other request for the target.
  • Wherever possible, restrict the usage of your forward functionality to some set of authorized users, instead of all unauthorized users.
  • Use weblogs to identify potential code. Look for HTTP status codes in the 300 series: 301, 302, 303, and 307.
  • Where possible, do not use redirect, or redirect to static locations.
  • When redirecting to a parameter, validate the parameter to make sure that it is an expected redirect. Use table indirection where possible to turn a dynamic set of potential choices into a table of valid keys. At the very least, allow only relative redirects.
Table Indirection Technique

If you have a potential set of valid locations that the client is allowed to redirect to, consider using table indirection. Maintain a table of allowed URIs, and then allow the client to specify the keys into the table only and not the actual URI itself.

When the key is returned, look up the URI in the table and then redirect to that location.

In the following URL, the color blue indicates user input, and the color grey is the unencoded value of the redirect parameter.

/Login.aspx?redirect=%2fAccount%3Fid%3d1234(/Account?id=1234)

          becomes

/Login.aspx?redirectKey=13&param1=1234

Even if your system requires additional data to be sent to the location, the table indirection can still be successful. Simply take the additional parameter and combine it with the URI value from the table. Be careful of any type of injection attack here; even though you are restricting the malicious user, you still need to validate the data in “param1”.

You can use the table indirection technique to mitigate unvalidated redirects and forwards. If you have a set of valid locations that the client is allowed to redirect to, consider using table indirection. Keep a table of the allowed URIs, and then allow the client to specify the keys into the table only and not the actual URI itself. When the key is returned, look up the URI in the table and then redirect to that location.

In the example on the screen, a redirection scheme for logging that takes a relative path directly becomes a system that uses a redirect key instead. The key value will either exist in the table or it won’t, and a malicious user has little control over the redirect destination.

Threats from earlier OWASP Top 10 List

This concludes the current OWASP Top 10 list, which was released in 2010. The previous list released in 2007 included two additional threats that were replaced by security misconfiguration and unvalidated redirects and forwards. These threats, while no longer included in the current top 10 list, are still important. They are:
  • Malicious File Execution
  • Information Leakage and Improper Error Handling
Malware

Malware can be spread as file uploads or file attachments.

Malware is a malicious program that shouldn’t be executing on a system.
  • A Worm is a self-propagating program.
  • A Virus requires user action such as copying files to propagate.
  • A Trojan Horse purports to be a benign or helpful program but harbors malicious behavior.
  • A Time Bomb may perform a malicious action after a predetermined date or time is reached

Malware is one of the most common malicious attacks that can be used for breaching application security. Attackers having access to upload or attach arbitrary files can spread malware from their computers to trusted systems. Then, remote or local users of the application may inadvertently execute these files. There are three major types of malwares Worm, Virus, and Trojan Horse.

A Worm is a self-propagating program that takes advantage of either a vulnerability in an operating system or a common software to breach a system and start executing malicious codes in the system. The Worm doesn’t stop here, it then searches for other systems with some vulnerability and repeats the process to spread itself. Worms can spread quickly and pose a major risk to a vulnerable network.

A Virus attaches them to an executable file infecting the file. When the infected file is moved to another system and executed, other files on that system become infected with the virus. A virus uses system resources and other programs to reproduce itself. 

A Trojan Horse is named after the famous Trojan Horse in Greek mythology. A Trojan Horse purports to be a beneficial program. However, it harbors malicious functionality such as a keystroke logger for capturing passwords or remote access that will allow an attacker to attack and control a system. Users are tricked into installing the malware, which is often disguised as a browser toolbar, a media player, a video codec, or an electronic greeting card.

Malicious File Execution

When user input is used to open files or execute commands, there is an opportunity for malicious code execution.

Guidelines for Preventing Malicious Code Execution
  • Never expose file identifiers to user input. 
  • Never use unfiltered user input to craft a filename or an OS exec input.
  • Don’t allow user input to create server-side script or include files.
Malicious code execution can be prevented by following some guidelines. You should never expose file identifiers to a user such that they become part of user input and can be easily modified by them. Exposing file identifiers can also cause information leakage by allowing the user select the filename opened by the application. Moreover, if the application executes commands or scripts contained in the file, this can lead to the more serious malicious code execution.

Suppose user input is part of an OS shell or an exec command. Then the user can specify commands to execute. Therefore, you should always filter user input going into system(), StartProcess(), java.lang.Runtime.exec(), System.Diagnostics.Process.Start() or similar APIs. 

Another malicious code execution is an include file injection. An include file injection occurs when the user is able to specify a filename as input that gets included into a running script under PHP. Script injection occurs when the user is able to specify input that is interpreted by the server-side scripting engine in PHP or ASP.

Information Leakage and Improper Error Handling

Information Leakage

Disclosing information in error messages is often done because it helps normal users to fix errors and help developers fix various problems. Examples of error messages that are likely to disclose information are ODBC error messages, authentication error messages, and others.

Improper Error Handling

Improper error handling can provide information that can be used for attacking a system. For example, error messages such as:
  • “Running V4.1 with X module”, can provide application/platform identification information.
  • “Error encountered at line 123 in file this_is_a_weak_app.asp” can provide application implementation details.
  • “Invalid password supplied for user id xxxxx.” can disclose accurate user ids.
Disclosing information in error messages is often done because it helps normal users to fix errors and help developers fix various problems. Examples of error messages that are likely to disclose information are ODBC error messages, authentication error messages, and others. 

Applications should handle error messages with a lot of restrictions. Improper error handling can provide information that can be used for attacking a system. For example, error messages should avoid application/platform identification information, implementation details, and information related to data quality.

Preventing Information Leakage and Improper Error Handling

Determine in advance:
  • What is reasonable and can be disclosed.
  • What is not to be disclosed.
Think from an attacker’s perspective.

Use a standard error response for all sensitive data errors. Such as “An error has occurred while accessing the database.”

To prevent information leakage, one must segregate information based on some pre-defined criteria. You should determine in advance about which information is safe for disclosure and which information needs protection.

The best way to determine the level of information confidentiality is by thinking from an attacker’s perspective and determining what the attacker can do with the information.

Even while developing error-handling messages for an application you should use a standard error response for all sensitive data errors. Just mention the macro problem, such as “An error has occurred accessing the database”.

Layered Security / Defense in Depth

Layered Security, or Defense in Depth, is the strategy of using several concurrent methods, such as point security solutions, filtering systems, and monitoring strategies, to protect information technology resources and data. Layered Security addresses security vulnerabilities in personnel, technology, and operations for the duration of the system’s lifecycle. This approach to security makes it more difficult and time consuming for an attacker to mount an attack and limits what the attacker can access with each successful penetration. Here, the placement of protection mechanisms, procedures, and policies is intended to increase the dependability of an information technology system with multiple layers of defense to prevent direct attacks against critical systems.

The Layered Security approach acknowledges that there isn’t a “silver bullet” and that even the best single security countermeasure might fail. Let’s consider the onion defense vs. the eggshell defense example to understand this. As soon as you peel a layer off an onion, there is another layer to get through. There are many layers, each of which needs to be peeled. In contrast, once an eggshell is cracked, the interior of the egg is completely exposed. 

Therefore, you should not rely on only one security mechanism. If there is a flaw in that security mechanism, the attacker will successfully access the data of your application.

Another example of multiple security layers can be of a bank branch office. In a bank, there are many layers of security that safeguard the money held in the bank vault. If you just pick the lock on the front door of the branch, you still have many layers of defense between you and the money.

One technical example of incorporating multiple layers of security is to use input validation combined with a low-privileged, read-only database account to protect against SQL injection. In this scenario, even if the attacker is able to circumvent the input validation, he will only be able to run a limited subset of queries against the database and will not be able to alter data.

Segmentation

Segmentation is the practice of separating data from logic, segmenting data by privilege, and segmenting applications from the environment to improve security.

A common example of segmenting data from logic is housing data in a database on a non-publicly accessible system and configuring the Web root of your Web server on a separate partition from the operating system installation.

The other way of segmenting data is by privilege. Segmenting data by privilege separates data by the authorization level required to access it. Database tables, Web folders, and configuration files are potential areas where privilege based segmentation could be applied.

An application can also be segmented from its environment. This confines the application to a “safe space” where its access to the system resources is tightly constrained. Examples include the Java sandbox, Unix chroot, and .NET Code Access Security.

Principle of Least Privilege

To help maintain security, all entities (people, processes, devices) should be assigned the fewest privileges consistent with their assigned duties and functions.

Definition
  • Each user, program, and program component operates using the fewest privileges required for proper functionality.

Rationale
  • Limits damage from an accident, an error, or an attack.
  • Reduces interactions among privileged programs.
  • Limits successful attackers to only assume the authority associated with the compromised account.

Examples
  • Users get only the privileges they require to do their job.
  • Administrators only login with admin privileges when they absolutely need it.
  • Applications only open files with the specific permissions that are required.
Default Deny

The Default Deny principle explains that access to resources and all application input should be denied unless specifically permitted. It is more effective to use a white-list technique for input in which you list all the acceptable input rather than try to filter out or deny all the unacceptable input with a black list. An attacker is much more likely to bypass a blacklist than a whitelist. User permissions should default to deny with exceptions for the permissions allowed rather than try to explicitly specify which permissions are disallowed.

As part of the default deny principle, when an invalid transaction error occurs, you should terminate all other transactions until the invalid transaction is properly addressed.

Input / Data Validation

Failing to properly validate input is one of the most common mistakes that application developers make. Ineffective input validation can lead to system crashes, malicious database manipulation, execution of attacker-controlled code, database corruption, and other breaches of application confidentiality, integrity, and availability.

Attacks can be run against applications that insert malformed data, which can confuse, crash, or make the application divulge too much information to the attacker.

There are three main models to think about when designing a data validation strategy: Accept Only Known Valid Data, Reject Known Bad Data, and Sanitize Bad Data.

"Accept Only Known Valid Data" is the best model. All three models must check: data type, character set, range, and length.

Good input validation routines involve the participation of Architects, Developers, and QA.

Input / Data Validation   Best Practices

While designing input or data validation strategies, you should not trust another layer or module to modify or sanitize data. You should use regular expressions to allow only acceptable data into the application.

The types of input validation options you can perform include exact, whitelist, and blacklist. Exact is the best of the three types, followed by whitelist, and blacklist. This is because exact filtering checks for a specific, well-defined data format, such as a phone number or state name. Whitelist filtering checks for a set of known good characters, while blacklist filtering checks for a set of known bad characters.

After input validation, the last step of any validation should be to perform business logic validation. Business logic validation will be unique to your application and will ensure that the input follows the rules required by your code to work. For instance, you may check that a credit card is legitimate or that the name on the credit card matches the name in your database.

Test Everything

It is important to perform security testing to catch improper design and coding practices that may have been missed earlier in your development process:
  • Never assume that security controls are effective until you can validate them with thorough testing.
  • Most security vulnerabilities will not be discovered during normal application use.
  • Allocate time for dedicated security testing within your project timeline.
  • Always test applications and application components, both in isolation and in the environment where the application is deployed.
Authentication

The authentication process verifies the identity of an entity. The entity could be a computer or a computer user. Trust is established based on the quality of your authentication implementation and the strength of the entity-provided credentials.

Common authentication mechanisms include:
  • Passwords
  • X.509 Certificates
  • Kerberos Tickets
  • Smart Cards
  • Tokens
  • Biometrics
Authentication Considerations

All authentication methods have weaknesses and can be breached because of poor implementation. Security vulnerabilities can occur in implementations that include passwords, certificates, or even biometrics.

The authentication process is often attacked first because even an unauthenticated user can access the login page of your application.

To strengthen the authentication process, you can use two-factor authentication. Two-factor authentication provides added security by simultaneously using two different factors to verify users. In two-factor authentication, a user must know something unique and posses something unique. For example, knowing a password and possessing a hard token to login to a system.

Authorization

The authorization process:
  • Determines and grants rights to an authenticated entity.
  • Often uses Access Control Lists (ACLs) for resource-based authorization.
  • May use LDAP servers to store information about user roles and privilege levels.
Common authorization techniques are:
  • Resource-based authorization, such as Access Control Lists (ACLs).
  • Role-based authorization, such as LDAP or Active Directory.
Authorization is the process of determining the rights that should be granted to an authenticated entity.

After the identity of a user is authenticated, an application authorizes a user to perform actions in the system based upon the permissions associated with the authenticated identity or the permissions of the group or role that the identity belongs to.

Authorization can also be performed on specific resources, such as a database or a file on the file system. Access Control Lists (ACLs) are a common mechanism by which resource-based authorization is performed on the Windows operating system.

Authorization is similar to checking the guest list at an exclusive party or checking your opera ticket. In these cases, the security personnel verify the guest’s name against the guest list. In this analogy, authentication is checking the ID and authorization is checking that name against the list of allowed guests.

Similarly, authorization is often achieved via Access Control Lists (ACLs). You can grant or deny access based on a wide variety of criteria, such as the network address of the client or the time of day.

Access control permits and restricts user entry. It behaves like a gate that closes after a stipulated time or a gate that only allows employees to enter the premises of an organization.

Authorization Considerations

Authorization Considerations

Use access controls to structurally harden your environment. Keep in mind that thoughtful segmentation will facilitate authorization.

Use the principle of least privilege and grant each entity the minimum privileges required for proper business functionality.

Scrutinize integration with other components. Define responsibility and examine implementation carefully.

Ask yourself, “What type of access does my application need?”
  • Log files
  • Configuration files
  • Database tables
Testing for Specific Types of Vulnerabilities

Examples of classes of security defects, along with their definition, that software should be verified against:

  • Buffer overflows. A programming error that may result in unauthorized memory access and arbitrary code execution on the victim host. Only affects native code.

  • SQL injection. A type of vulnerability caused by improper inclusion of user-specified parameters into an SQL query that can allow an attacker to change the behavior of the query when it is executed by a backend database.

  • Cross-site scripting. A category of security vulnerabilities common in Web applications that allow code to be injected by malicious Web users into Web pages viewed by other users.

  • Lack of server-side authorization. A vulnerability affecting client-server applications caused by the fact that authorization is performed on the client. By exploiting this type of vulnerability, attackers may illegally access the assets of the system.

  • Weak authentication. A type of flaw that allows attackers to bypass authentication and, therefore, access resources of the system inappropriately.

  • Weak authorization. A class of vulnerability that allows authorization to be bypassed. By exploiting this type of flaw, attackers can potentially elevate their level of privilege by accessing resources that they otherwise would not have access to.

  • Improper use of cryptography. A type of vulnerability caused by the insecure use of cryptographic mechanisms such as encryption and hashing functions.

  • Improper error handling. A category of vulnerabilities that can result in sensitive information being revealed to attackers or the application being in an insecure state.