Secure Your Organization’s Internal Resources

Learning Objectives

After completing this unit, you’ll be able to:

Explain the dangers of broken authentication and session management.
Prevent sensitive data from exposure.
Defend against broken access control.

What Are Internal Resources?

Internal resources are the safety features you build into your code to ensure that your processes, policies, and procedures protect your organization’s assets and the trust your customers place in you. Let’s now take a look at the three internal resource controls covered in the Open Web Application Security Project (OWASP) Top 10: broken authentication and session management, sensitive data exposure, and broken access control.

How Broken Authentication and Session Management Exposes Data

Authentication is the process of proving or showing something to be true, genuine, or valid. In computer systems, this usually means proving you are who you say you are and that you should be able to access a given resource. You can often do so by providing a username and password, inputting a one-time code, or approving a request sent to an application on your mobile device.

Session management refers to the process of securely handling multiple requests to a web application or service from a single user or entity. Typically a session starts when a user authenticates their identity using a username and password or other authentication protocol.

Authentication and session management weaknesses can allow attackers to access usernames and passwords. Session management attacks usually occur when attackers gain access to unexpired session tokens. A session token is an encrypted, unique identifier that corresponds to a specific session. An attacker can access a session and all user information contained in it if they know the session token to a protected resource, such as an application.

Weak session management leaves logged-in users vulnerable to attack. Let’s say that an application does not rotate session IDs after successful login or isn’t properly invalidating session IDs during logout or a period of inactivity. A user accesses the application on a public computer. Instead of selecting “log out,” the user closes the browser tab and walks away. An attacker uses the same browser an hour later and the user is still authenticated. Their sensitive data has been exposed.

What tools can you use to prevent a situation like this? You can use strong authentication and secure token handling mechanisms.

Strong Authentication Mechanisms

These strong authentication mechanisms help keep accounts secure.

Strengthening Your Password Controls

Implement multi-factor authentication (MFA) and weak password checks. Follow best password practices for cybersecurity. Don’t ship or deploy systems with default credentials, particularly for administrative users.

Limiting Password Attempts

Limit password attempts and limit or increasingly delay failed login attempts to prevent attackers from using trial-and-error to guess login information.

Avoiding Verbose Failure Messages

Use login error messages like “Incorrect username or password” instead of user-friendly messages like “Your username is incorrect.” Such additional information aids attackers by telling them which part of the login attempt failed.

Session Management

Systems with weak session management include those that do the following.

Expose session IDs in the Uniform Resource Locator (URL).
Fail to rotate session IDs after successful login.
Fail to properly invalidate session IDs or authentication tokens during logout or after a period of inactivity.

These secure token handling mechanisms can help prevent breaches.

Use Strong Tokens

Use tokens that contain enough entropy (randomness) to prevent attackers from identifying their value. Do not generate your own session tokens. Web development frameworks such as Java EE (JEE), .NET, and Hypertext Preprocessor (PHP) provide session management features and implementation. Use the latest versions of these tried-and-tested, built-in frameworks that are utilized worldwide on multiple web environments.

Handle Tokens Securely

To protect the session ID exchange from active eavesdropping and passive disclosure in network traffic, use an encrypted Hypertext Transfer Protocol Secure (HTTPS) Transport Layer Security (TLS) connection for the entire web session, not just the authentication process. This helps protect the integrity and confidentiality of the data between the user’s computer and the site.

To ensure the session ID is exchanged only through an encrypted channel, use the secure cookie attribute, an option that can be set by the application server when sending a new cookie to the user within an HTTP Response. Using encrypted communication channels protects the session against fixation attacks where the attacker is able to intercept and manipulate web traffic to inject (or fix) the session ID on the victim’s web browser.

Prevent Data Exposure

Encryption conceals information by using complex algorithms to scramble data so that it appears random. Once received, the data can be decrypted using a key.

Sensitive data is in danger of exposure any time it is not encrypted. Data exposure can also occur due to weak key generation and management, weak algorithms, improper protocol for data exchange on the web, and substandard cipher usage to encrypt internet traffic.

There are several ways to minimize data exposure:

Don’t store sensitive data unless it is absolutely necessary. If you must do so, make sure it is encrypted and discard it as soon as possible.
Use up-to-date, strong, standard algorithms, protocols, and keys. Not all algorithms are created equal. For instance, the Message Digest algorithm 5 (MD5) and Rivest Cipher 4 (RC4) algorithms are known to have extensive vulnerabilities and thus should never be used to secure data. Use proper key management and encrypt all data in transit with transport layer security (TLS) and enforce encryption with HTTP Strict Transport Security (HSTS).
Disable caching for responses that contain sensitive data. Store passwords using strong, nonreversible, adaptive, and salted hashing functions with a work factor such as Argon2, scrypt, bcrypt, or password-based key derivation function (PBKDF2). A salted hash function is one that adds extra random data, which further protects the output from common methods of attack. A work factor is the number of times an algorithm is run.

A hashing algorithm represented by a funnel converts documents into a secure form of storage, symbolized by a padlock.

Defend Against Broken Access Control

Access control refers to how you restrict users’ permissions. Access control failure leads to consequences like unauthorized information disclosure, modification or destruction of data, and performance of business functions outside a user’s limits. Common access control vulnerabilities include the following.

Bypassing access control checks.
Allowing the primary key or unique identifier to be changed to another user’s record.
Elevating a user’s privilege.
Manipulating metadata.
Forced browsing to authenticated pages as an unauthenticated user or to privileged pages as a standard user.
Allowing access to application programming interfaces (APIs) with missing access controls for POST, PUT, and DELETE Hypertext Transfer Protocol (HTTP) methods. These commands correspond to create, update, and delete, respectively, and are some of the most commonly used HTTP verbs.

Here are examples of code that are vulnerable to broken access control attacks.

Scenario 1: The application uses unverified data in a SQL call accessing account information.

pstmt.setString(1, request.getParameter("acct"));ResultSet results = pstmt.executeQuery( );

Attackers modify the “acct” parameter in the browser to send whatever account number they choose. If not properly verified, attackers can access any user's account.

http://example.com/app/accountInfo?acct=notmyacct

Scenario 2: An attacker forces a browser to target URLs. Administrative rights are required for access to the administrative page.

http://example.com/app/getappInfohttp://example.com/app/admin_getappInfo

If an unauthenticated user can access either page, it’s a flaw. If a nonadministrative user can access the administrative page, it’s a flaw.

Now that you’re familiar with the consequences of broken access control, it’s time to learn how to prevent these types of attacks.

Preventing Broken Access Control Attacks

Access control is effective only if enforced in trusted server-side code or a serverless API, where attackers can’t modify the access control check or metadata. Here are some ways to prevent attacks.

Deny by default. Implement access control mechanisms only once, then reuse them throughout the application. This creates a single location to troubleshoot and prevents conflicting access controls.
Set access controls so that users can't create, read, update, or delete them.
Design your application to function only in the domain it needs and ensure that web server directory listings are disabled.
Log access control failures and rate limit API and controller access.
Invalidate JavaScript Object Notation (JSON) Web Tokens (JWT) after logout.
Include functional access control, unit, and integration tests, which test a slice of the program to ensure it is performing as expected.

Sum It Up

As a developer, you have a responsibility to keep security principles like confidentiality, integrity, and availability in mind. In this module, you’ve learned about some of the most common application security vulnerabilities, best practices, and remediations in order to protect your organization. Interested in learning more about cybersecurity best practices? Check out the Cybersecurity Learning Hub on Trailhead.

Looking for Help?