Chapter 6 - Application Security

VI. APPLICATION SECURITY

Secure Coding Practices

Web Application Security: OWASP Top 10
Mobile Application Security

1. Demonstrate proficiency in implementing secure coding practices to mitigate common vulnerabilities and
threats in software development.
2. Analyze and assess web applications using the OWASP Top 10 list, identifying vulnerabilities and applying
appropriate security measures to mitigate risks effectively.
3. Evaluate and implement security measures to safeguard mobile applications against common security
threats, ensuring the confidentiality, integrity, and availability of sensitive data.

8 Best Secure Coding Practices

by Tori Thurmond / December 27th, 2023

When you hire builders to construct a new home, you expect them to take every precaution to ensure once you move
in, you won’t find split beams, foundational errors, or holes in the walls. In the same way, software developers are
expected to uphold secure coding practices to ensure they aren’t leaving any vulnerabilities open for hackers to
exploit.

What is Secure Coding?

Secure coding standards govern the coding practices, techniques, and decisions that developers make while building
software. They aim to ensure that developers write code that minimizes security vulnerabilities. Development tasks
can be solved in many different ways, with varying levels of complexity. Some solutions are more secure than others,
and secure coding standards encourage developers and software engineers to take the safest approach, even if it is
not the fastest.

For example, secure coding best practices often mandate a “default deny” approach to access permissions. Developers
using secure coding techniques create code that denies access to sensitive resources unless an individual can
demonstrate that they are authorized to access it.

There are several secure coding standards and coding security guides in widespread use today, including the OWASP
Secure Coding Practices and the SEI CERT Coding Standards.

Why You Should Use Secure Coding Standards?

In the 2017 breach at Equifax, malicious individuals accessed personal information because of compromised software
at the foundation of their organization. That isn’t the first organization, or the last, to find holes in its secure coding
practices and leave themselves open to exploitation.

According to a 2020 survey completed by Sonatype, 24% or respondents confirmed or suspected a breach related to
their application development practices. That number is staggering when you consider the odds that your organization
will be next to experience a breach if you don’t initiate coding security best practices.

8 Secure Coding Best Practices

OWASP provides a secure coding practices checklist that includes 14 areas to consider in your software development
life cycle. Of those secure coding practices, we’re going to focus on the top eight secure programming best practices to
help you protect against vulnerabilities.
• Security by Design
• Password Management
• Access Control
• Error Handling and Logging
• System Configuration
• Threat Modeling
• Cryptographic Practices
 • Input Validation and Output Encoding

Security by Design
Security needs to be a priority as you develop code, not an afterthought. Organizations may have competing priorities
where software engineering and coding are concerned. Following software security best practices can conflict with
optimizing for development speed. However, a “security by design” approach that puts security first tends to pay off in
the long run, reducing the future cost of technical debt and risk mitigation. An analysis of your source code should be
conducted throughout your software development life cycle (SDLC), and security automation should be implemented.

Password Management
Passwords are a weak point in many software systems, which is why multi-factor authentication has become so
widespread. Nevertheless, passwords are the most common security credential, and following secure coding practices
limits risk. You should require all passwords to be of adequate length and complexity to withstand any typical or
common attacks. OWASP suggests several coding best practices for passwords, including:

Storing only salted cryptographic hashes of passwords and never storing plain-text passwords
Enforcing password length and complexity requirements
Disable password entry after multiple incorrect login attempts
Implementing logical access controls like password policies can do wonders for strengthening your organization’s
security posture.

Access Control
Take a “default deny” approach to sensitive data. Limit privileges and restrict access to secure data to only users who
need it. Deny access to any user that cannot demonstrate authorization. Ensure that requests for sensitive information
are checked to verify that the user is authorized to access it.

Error Handling and Logging

Software errors are often indicative of bugs, many of which cause vulnerabilities. Error handling and logging are two of
the most useful techniques for minimizing their impact. Error handling attempts to catch errors in the code before
they result in a catastrophic failure. Logging documents errors so that developers can diagnose and mitigate their
cause.

Documentation and logging of all failures, exceptions, and errors should be implemented on a trusted system to
comply with secure coding standards.

System Configuration
Clear your system of any unnecessary components and ensure all working software is updated with current versions
and patches. If you work in multiple environments, make sure you’re managing your development and production
environments securely.

Outdated software is a major source of vulnerabilities and security breaches. Software updates include patches that
fix vulnerabilities, making regular updates one of the most vital, secure coding practices. A patch management system
may help your business to keep on top of updates.

Threat Modeling
Document, locate, address, and validate are the four steps to threat modeling. To securely code, you need to examine
your software for areas susceptible to increased threats of attack. Threat modeling is a multi-stage process that should
be integrated into the software lifecycle from development, testing, and production.

Cryptographic Practices
Encrypting data with modern cryptographic algorithms and following secure key management best practices increases
the security of your code in the event of a breach.

Input Validation and Output Encoding

It’s important to identify all data inputs and sources and validate those classified as untrusted. You should utilize a
standard routine for output encoding and input validation.

How to Ensure Your Code Is Secure

By patching your systems regularly, you’re taking these secure coding guidelines to the next level. Patch and
vulnerability management is focused on identifying risk and enabling systems to stay up to date. Through these
methods and security testing, you’re ensuring that your code is properly checked for errors.
Secure Coding Practices Checklist
Input validation
• Conduct all input validation on a trusted system (server side not client side).
• Identify all data sources and classify them into trusted and untrusted.
• Validate all data from untrusted sources (databases, file streams, etc).
• Use a centralized input validation routine for the whole application.
• Specify character sets, such as UTF-8, for all input sources (canonicalization).
• Encode input to a common character set before validating.
• All validation failures should result in input rejection.
• If the system supports UTF-8 extended character sets and validate after UTF-8 decoding is completed.
• Validate all client provided data before processing.
• Verify that protocol header values in both requests and responses contain only ASCII characters.
• Validate data from redirects.
• Validate for expected data types using an "allow" list rather than a "deny" list.
• Validate data range.
• Validate data length.
• If any potentially hazardous input must be allowed, then implement additional controls.
• If the standard validation routine cannot address some inputs, then use extra discrete checks.
• Utilize canonicalization to address obfuscation attacks.

Output encoding
• Conduct all output encoding on a trusted system (server side not client side).
• Utilize a standard, tested routine for each type of outbound encoding.
• Specify character sets, such as UTF-8, for all outputs.
• Contextually output encodes all data returned to the client from untrusted sources.
• Ensure the output encoding is safe for all target systems.
• Contextually sanitize all output of un-trusted data to queries for SQL, XML, and LDAP.
• Sanitize all output of untrusted data to operating system commands.

Authentication and password management

• Require authentications for all pages and resources, except those specifically intended to be public.
• All authentication controls must be enforced on a trusted system.
• Establish and utilize standard, tested, authentication services whenever possible.
• Use a centralized implementation for all authentication controls, including libraries that call external authentication
services.
• Segregate authentication logic from the resource being requested and use redirection to and from the centralized
authentication control.
• All authentication controls should fail securely.
• All administrative and account management functions must be at least as secure as the primary authentication
mechanism.
• If your application manages a credential store, use cryptographically strong one-way salted hashes.
• Password hashing must be implemented on a trusted system server side not client side).
• Validate the authentication data only on completion of all data input.
• Authentication failure responses should not indicate which part of the authentication data was incorrect.
• Utilize authentication for connections to external systems that involve sensitive information or functions.
• Authentication credentials for accessing services external to the application should be stored in a secure store.
• Use only HTTP POST requests to transmit authentication credentials.
• Only send non-temporary passwords over an encrypted connection or as encrypted data.
• Enforce password complexity requirements established by policy or regulation.
• Enforce password length requirements established by policy or regulation.
• Password entry should be obscured on the user's screen.
• Enforce account disabling after an established number of invalid login attempts.
• Password reset and changing operations require the same level of control as account creation and authentication.
• Password reset questions should support sufficiently random answers.
• If using email-based resets, only send email to a pre-registered address with a temporary link/password.
• Temporary passwords and links should have a short expiration time.
• Enforce the changing of temporary passwords on the next use.
• Notify users when a password reset occurs.
• Prevent password re-use.
• Passwords should be at least one day old before they can be changed, to prevent attacks on password re-use.
• Enforce password changes based on requirements established in policy or regulation, with the time between resets
administratively controlled.
• Disable "remember me" functionality for password fields.
 • The last use (successful or unsuccessful) of a user account should be reported to the user at their next successful login.
• Implement monitoring to identify attacks against multiple user accounts, utilizing the same password.
• Change all vendor-supplied default passwords and user IDs or disable the associated accounts.

• Re-authenticate users prior to performing critical operations.

• Use Multi-Factor Authentication for highly sensitive or high value transactional accounts.
• If using third party code for authentication, inspect the code carefully to ensure it is not affected by any malicious code.

Session management
• Use the server or framework’s session management controls. The application should recognize only these session
identifiers as valid.
• Session identifier creation must always be done on a trusted system (server side not client side).
• Session management controls should use well vetted algorithms that ensure sufficiently random session identifiers.
• Set the domain and path for cookies containing authenticated session identifiers to an appropriately restricted value for
the site.
• Logout functionality should fully terminate the associated session or connection.
• Logout functionality should be available from all pages protected by authorization.
• Establish a session inactivity timeout that is as short as possible, based on balancing risk and business functional
requirements.
• Disallow persistent logins and enforce periodic session terminations, even when the session is active.
• If a session was established before login, close that session and establish a new session after a successful login.
• Generate a new session identifier on any re-authentication.
• Do not allow concurrent logins with the same user ID.
• Do not expose session identifiers in URLs, error messages or logs.
• Implement appropriate access controls to protect server-side session data from unauthorized access from other users of
the server.
• Generate a new session identifier and deactivate the old one periodically.
• Generate a new session identifier if the connection security changes from HTTP to HTTPS, as can occur during
authentication.
• Consistently utilize HTTPS rather than switching between HTTP to HTTPS.
• Supplement standard session management for sensitive server-side operations, like account management, by utilizing
per-session strong random tokens or parameters.
• Supplement standard session management for highly sensitive or critical operations by utilizing per-request, as opposed
to per-session, strong random tokens or parameters.
• Set the "secure" attribute for cookies transmitted over a TLS connection.
• Set cookies with the HttpOnly attribute, unless you specifically require client-side scripts within your application to read
or set a cookie's value.

Access control
• Use only trusted system objects, e.g. server-side session objects, for making access authorization decisions.
• Use a single site-wide component to check access authorization. This includes libraries that call external authorization
services.
• Access controls should fail securely.
• Deny all access if the application cannot access its security configuration information.
• Enforce authorization controls on every request, including those made by server-side scripts.
• Segregate privileged logic from other application code.
• Restrict access to files or other resources, including those outside the application's direct control, to only authorized
users.
• Restrict access to protected URLs to only authorized users.
• Restrict access to protected functions to only authorized users.
• Restrict direct object references to only authorized users.
• Restrict access to services to only authorized users.
• Restrict access to application data to only authorized users.
• Restrict access to user and data attributes and policy information used by access controls.
• Restrict access security-relevant configuration information to only authorized users.
• Server-side implementation and presentation layer representations of access control rules must match.
• If state data must be stored on the client, use encryption and integrity checking on the server side to detect state
tampering.
• Enforce application logic flows to comply with business rules.
• Limit the number of transactions a single user or device can perform in a given period of time, low enough to deter
automated attacks but above the actual business requirement.
• Use the "referrer" header as a supplemental check only, it should never be the sole authorization check as it is can be
spoofed.
 • If long authenticated sessions are allowed, periodically re-validate a user’s authorization to ensure that their privileges
have not changed and if they have, log the user out and force them to re-authenticate.
• Implement account auditing and enforce the disabling of unused accounts.
• The application must support disabling of accounts and terminating sessions when authorization ceases.
• Service accounts or accounts supporting connections to or from external systems should have the least privilege
possible.
• Create an Access Control Policy to document an application's business rules, data types and access authorization criteria
and/or processes so that access can be properly provisioned and controlled. This includes identifying access
requirements for both the data and system resources.

Cryptographic practices
• All cryptographic functions used to protect secrets from the application user must be implemented on a trusted system.
• Protect secrets from unauthorized access.
• Cryptographic modules should fail securely.
• All random numbers, random file names, random GUIDs, and random strings should be generated using the
cryptographic module’s approved random number generator.
• Cryptographic modules used by the application should be compliant to FIPS 140-2 or an equivalent standard.
• Establish and utilize a policy and process for how cryptographic keys will be managed.

Error handling and logging

• Do not disclose sensitive information in error responses, including system details, session identifiers or account
information.
• Use error handlers that do not display debugging or stack trace information.
• Implement generic error messages and use custom error pages.
• The application should handle application errors and not rely on the server configuration.
• Properly free allocated memory when error conditions occur.
• Error handling logic associated with security controls should deny access by default.
• All logging controls should be implemented on a trusted system.
• Logging controls should support both success and failure of specified security events.
• Ensure logs contain important log event data.
• Ensure log entries that include un-trusted data will not execute as code in the intended log viewing interface or software.
• Restrict access to logs to only authorized individuals.
• Utilize a central routine for all logging operations.
• Do not store sensitive information in logs, including unnecessary system details, session identifiers or passwords.
• Ensure that a mechanism exists to conduct log analysis.
• Log all input validation failures.
• Log all authentication attempts, especially failures.
• Log all access control failures.
• Log all apparent tampering events, including unexpected changes to state data.
• Log attempts to connect with invalid or expired session tokens.
• Log all system exceptions.
• Log all administrative functions, including changes to the security configuration settings.
• Log all backend TLS connection failures.
• Log cryptographic module failures.
• Use a cryptographic hash function to validate log entry integrity.

Data protection
• Implement least privilege, restrict users to only the functionality, data and system information that is required to perform
their tasks.
• Protect all cached or temporary copies of sensitive data stored on the server from unauthorized access and purge those
temporary working files as soon as they are no longer required.
• Encrypt highly sensitive stored information, such as authentication verification data, even if on the server side.
• Protect server-side source-code from being downloaded by a user.
• Do not store passwords, connection strings or other sensitive information in clear text or in any non-cryptographically
secure manner on the client side.
• Remove comments in user accessible production code that may reveal backend system or other sensitive information.
• Remove unnecessary applications and system documentation as this can reveal useful information to attackers.
• Do not include sensitive information in HTTP GET request parameters.
• Disable auto complete features on forms expected to contain sensitive information, including authentication.
• Disable client-side caching on pages containing sensitive information.
• The application should support the removal of sensitive data when that data is no longer required.
• Implement appropriate access controls for sensitive data stored on the server. This includes cached data, temporary files
and data that should be accessible only by specific system users.
Communication security
• Implement encryption for the transmission of all sensitive information. This should include TLS for protecting the
connection and may be supplemented by discrete encryption of sensitive files or non-HTTP based connections.
• TLS certificates should be valid and have the correct domain name, not be expired, and be installed with intermediate
certificates when required.
• Failed TLS connections should not fall back to an insecure connection.
• Utilize TLS connections for all content requiring authenticated access and for all other sensitive information.
• Utilize TLS for connections to external systems that involve sensitive information or functions.
• Utilize a single standard TLS implementation that is configured appropriately.
• Specify character encodings for all connections.
• Filter parameters containing sensitive information from the HTTP referrer, when linking to external sites.

System configuration
• Ensure servers, frameworks and system components are running the latest approved version.
• Ensure servers, frameworks and system components have all patches issued for the version in use.
• Turn off directory listings.
• Restrict the web server, process and service accounts to the least privileges possible.
• When exceptions occur, fail securely.
• Remove all unnecessary functionality and files.
• Remove test code or any functionality not intended for production, prior to deployment.
• Prevent disclosure of your directory structure in the robots.txt file by placing directories not intended for public indexing
into an isolated parent directory.
• Define which HTTP methods, Get or Post, the application will support and whether it will be handled differently on
different pages in the application.
• Disable unnecessary HTTP methods.
• If the web server handles different versions of HTTP, ensure that they are configured in a similar manner and ensure any
differences are understood.
• Remove unnecessary information from HTTP response headers related to the OS, web-server version and application
frameworks.
• The security configuration store for the application should be able to be output in human readable form to support
auditing.
• Implement an asset management system and register system components and software in it.
• Isolate development environments from the production network and provide access only to authorized development
and test groups.
• Implement a software change control system to manage and record changes to the code both in development and
production.

Database security
• Use strongly typed parameterized queries.
• Utilize input validation and output encoding and be sure to address meta characters. If these fail, do not run the
database command.
• Ensure that variables are strongly typed.
• The application should use the lowest possible level of privilege when accessing the database.
• Use secure credentials for database access.
• Connection strings should not be hard coded within the application. Connection strings should be stored in a separate
configuration file on a trusted system, and they should be encrypted.
• Use stored procedures to abstract data access and allow for the removal of permissions to the base tables in the
database.
• Close the connection as soon as possible.
• Remove or change all default database administrative passwords.
• Turn off all unnecessary database functionality.
• Remove unnecessary default vendor content (for example sample schemas).
• Disable any default accounts that are not required to support business requirements.
• The application should connect to the database with different credentials for every trust distinction (for example user,
read-only user, guest, administrators).

File management
• Do not pass user supplied data directly to any dynamic include function.
• Require authentication before allowing a file to be uploaded.
• Limit the type of files that can be uploaded to only those types that are needed for business purposes.
• Validate uploaded files are the expected type by checking file headers rather than by file extension.
• Do not save files in the same web context as the application.
• Prevent or restrict the uploading of any file that may be interpreted by the web server.
• Turn off execution privileges on file upload directories.
 • Implement safe uploading in UNIX by mounting the targeted file directory as a logical drive using the associated path or
the chrooted environment.
• When referencing existing files, use an allow-list of allowed file names and types.
• Do not pass user supplied data into a dynamic redirect.
• Do not pass directory or file paths, use index values mapped to pre-defined list of paths.
• Never send the absolute file path to the client.
• Ensure application files and resources are read-only.
• Scan user uploaded files for viruses and malware.

Memory management
• Utilize input and output controls for untrusted data.
• Check that the buffer is as large as specified.
• When using functions that accept a number of bytes ensure that NULL termination is handled correctly.
• Check buffer boundaries if calling the function in a loop and protect against overflow.
• Truncate all input strings to a reasonable length before passing them to other functions.
• Specifically close resources don’t rely on garbage collection.
• Use non-executable stacks when available.
• Avoid the use of known vulnerable functions.
• Properly free allocated memory upon the completion of functions and at all exit points.
• Overwrite any sensitive information stored in allocated memory at all exit points from the function.

General coding practices

• Use tested and approved managed code rather than creating new unmanaged code for common tasks.
• Utilize task specific built-in APIs to conduct operating system tasks. Do not allow the application to issue commands
directly to the Operating System, especially through the use of application-initiated command shells.
• Use checksums or hashes to verify the integrity of interpreted code, libraries, executables, and configuration files.
• Utilize locking to prevent multiple simultaneous requests or use a synchronization mechanism to prevent race conditions.
• Protect shared variables and resources from inappropriate concurrent access.
• Explicitly initialize all your variables and other data stores, either during declaration or just before the first usage.
• In cases where the application must run with elevated privileges, raise privileges as late as possible, and drop them as
soon as possible.
• Avoid calculation errors by understanding your programming language's underlying representation.
• Do not pass user supplied data to any dynamic execution function.
• Restrict users from generating new code or altering existing code.
• Review all secondary applications, third party code and libraries to determine business necessity and validate safe
functionality.
• Implement safe updating using encrypted channels.
OWASP top 10
The Open Worldwide Application Security Project (OWASP) is a nonprofit foundation dedicated to improving software security. It
operates under an “open community” model, which means that anyone can participate in and contribute to OWASP-related
online chats, projects, and more. For everything from online tools and videos to forums and events, the OWASP ensures that its
offerings remain free and easily accessible through its website.

The OWASP Top 10 provides rankings of—and remediation guidance for—the top 10 most critical web application security risks.
Leveraging the extensive knowledge and experience of the OWASP’s open community contributors, the report is based on a
consensus among security experts from around the world. Risks are ranked according to the frequency of discovered security
defects, the severity of the uncovered vulnerabilities, and the magnitude of their potential impacts. The purpose of the report is
to offer developers and web application security professionals insight into the most prevalent security risks so that they may fold
the report’s findings and recommendations into their own security practices, thereby minimizing the presence of known risks in
their applications.

How is the OWASP Top 10 list used and why is it important?

The OWASP has maintained its Top 10 list since 2003, updating it every two or three years in accordance with advancements and
changes in the AppSec market. The list’s importance lies in the actionable information it provides in serving as a checklist and
internal web application development standard for many of the world’s largest organizations.
Auditors often view an organization’s failure to address the OWASP Top 10 as an indication that it may be falling short on other
compliance standards. Conversely, integrating the Top 10 into the software development life cycle (SDLC) demonstrates an
organization’s overall commitment to industry best practices for secure development.

Why is the OWASP Top 10 Important?

OWASP Top 10 is a research project that offers rankings of and remediation advice for the top 10 most serious web application
security dangers. The report is founded on an agreement between security experts from around the globe. The risks are graded
according to the severity of the vulnerabilities, the frequency of isolated security defects, and the degree of their possible
impacts.

The aim of the report is to provide web application security experts and developers with an understanding into the most
common security risks so that they can use the findings of the report as part of their security practices. This can help limit the
presence of such known risks within their web applications.

OWASP manages the Top 10 list and has been doing so since 2003. They update the list every 2-3 years, in keeping with changes
and developments in the AppSec market. OWASP provides actionable information and acts as an important checklist and internal
Web application development standard for a lot of the largest organizations in the world.

Auditors tend to see an organization’s remiss to address the OWASP Top 10 as a sign that it may not be up-to-scratch regarding
compliance standards. Employing the Top 10 into its software development life cycle (SDLC) shows a general valuing of the
industry’s best practices for secure development.

What’s new in the 2021 list?

For the 2021 list, the OWASP added three new categories, made four changes to naming and scoping, and did some
consolidation.

Broken Access Control (A01:2021).

This means that the user can do something that the user is not allowed to do. In other words, the user does not have permission
to perform some action. This can be done by a direct trial and error method or by increasing the authorization level in some way.

Imagine that a customer at the lane reaches inside the window and starts placing an order on the customer service computer.
This could also be a deliberate action, where the cashier just turns the computer screen towards the customer and hands the
keyboard to the customer. Another bad example would be if a customer could walk in the back door with some old restaurant
employee ID to place an order with their own hands.
The fix
Make sure to use the least privileged rights. Only grant users the permissions they need. Get rid of old and unused features to
reduce the attack surface. One day this old feature will not be updated to meet today’s requirements and the possibility of a new
vulnerability has opened up. Also make sure that the user cannot elevate the privileges in some way. Get rid of old user accounts
and fix potential security issues when found.

From the perspective of the scenario, the customer should indeed place an order, but only with limited rights. The customer
does not need to use the computer directly. The rights are filtered with the restaurant interface, which in this case is the cashier
of the order hatch. The cashier takes the order and processes it on the restaurant’s computer. If there are old unused access
points, in this case the bad habit of the customers themselves to fill the order, get rid of them too.

Cryptographic Failures (A02:2021).

The purpose of encryption is to protect sensitive information from unauthorized eyes. Sensitive data can be data or system
commands. Once data integrity is gone, we can no longer trust it. Someone may have tampered with it or private sensitive
information may have been leaked to a third party. This problem is called cryptographic failures.

Imagine if we gave our order to some random guy who would take the order to the counter. Of course, we wouldn’t trust that
random guy. He might change the order on the way.

The fix
Protecting data and connections with signatures is the best way to fix this. Make sure you use an encrypted connection to the
recipient when sending messages. Using encrypted messages also helps us trust the information we receive. When protecting
sensitive information in your database, make sure you use good enough encryption. This way, sensitive information is safe if it
leaks, its ease of use. Unnecessary sensitive information is also deleted from the system.

From an example perspective, we have two options. The first is to place the order directly at the cashier. In the real world, this is
impossible because messages travel quite a distance before reaching the correct endpoint. Another option is to use some kind of
secret coding so that the cashier knows that the integrity of the order has not been compromised and comes from a real
customer.

Injection (A03:2021).
The injection risk has been at the top of the list for many years. It’s been here for a reason, because we’re talking about one
nasty risk. This vulnerability allows a malicious user to add extra spice to commands issued to services. With these additional
commands, evil Actors can take large or small steps toward their evil goals.

Suppose the customer could slip something into the order to try to influence the restaurant’s behavior? Imagine if the customer
adds after the order text “… and I don’t have to pay a cent for this order.” The dummy system (in this case the cashier) processes
the request without thinking about the results it would have.

The fix
It is important not to rely on any user input. Clean, filter and validate all input received by the systems. Even the data is sent by
your own friendly frontend server. Using parameterized queries is also good practice. It means that commands are separated
from data. When the system knows that there should be a number in this query, there is no room for options.

From an example point of view, we should try to replace the stupid cashier with a smarter one. Use input validation. When the
cashier hears the customer’s order, he doesn’t take it seriously. Humans are good at processing information intuitively. The
cashier should naturally have a question in mind, why should someone get a free lunch? Applications just do what they are told
to do without questioning if the query is absent from the program’s operating logic.

Insecure Design (A04:2021).

Applications can be designed with care and safety in mind from the beginning or with the fastest possible return on investment
in mind. Unfortunately, the latter mostly means that information security gives way to “more important features”. Insecure
design means that security is not built in, but is added afterwards when the product is ready enough. This fails in most cases and
is more expensive. Since it is more expensive to do, it is either hardly done or not done at all. For example, the application
architecture, how system and network layers are implemented, must be considered in the design. Fixing these later is expensive.

What if in our scenario the business owners were busy building a restaurant building. The sales window could be implemented
so that the computer is at such an angle that the customer can see the screen along with other sensitive information. Another
good example would be that the hatch locking mechanism is too complicated to use. As a result, employees just keep it open
because they are lazy.

The fix
Try to enable Secure Software Development Lifecycle. It means that security has moved to the left in the software development
life cycle. When starting a project, think about the risks considering the project and the product. What laws and conditions must
be taken into account. Test and raise issues on time, etc. Read more about SSDLC in Joona’s thorough blog post.
In our example, business owners should know how to run a business in this kind of restaurant. They should have designed the
facilities before there was brick on top of brick. Otherwise, the drive-thru does not work as a drive-thru and business stalls.

Security Misconfiguration (A05:2021).

Most of the security misconfigurations are done by accident, but deliberately weakening protections, such as closing a firewall or
leaving unnecessary network ports open, are also done on purpose. Forgetting to close unnecessary features or APIs, leaking
dangerous information in error messages, using default credentials and not segmenting the network are also good examples of
security mistakes.

One configuration error is when an employee forgets to lock the restaurant door when leaving the building at night. Anyone
walking by could get in just by trying the handle. Or perhaps a better example is that a temporary hole has been made next to
the door during the restaurant renovation. When the renovation was done, they forgot to close it. Also, what if the customer
could shout orders directly to the kitchen, completely bypassing the cashier.

The fix
As technology develops, we have more and more things to configure. Forgetting to set something up correctly is a common
human error. For this reason, we should also use automated tests to detect these security configuration errors. We should also
try to do things right from the start. Opening the firewall just because it’s the fastest way to get things done is tempting, but the
wrong move. Using default passwords in systems should also be made impossible.

If customers could shout orders directly to the kitchen while doing business, things could get messy pretty quickly. The checkout
should be built in such a way that bypassing the correct user interface, the cashier, is not possible. Also, the kitchen staff must
only take orders from a certain route, through the restaurant workers.

Vulnerable and Outdated Components (A06:2021).

Outdated components and tools are a growing threat. Defects and information security holes are found in products at an
accelerating rate these days. Products are increasingly built from various components, the safety of which we cannot fully
guarantee. This leads to the difficult situation of having to keep track of what we have and what the states of those components
are.

What if the lock on the restaurant door in our example was the best that money could buy in the 19th century. The company that
made the lock still exists and has improved its lock systems several times in recent years. The door can be used, it looks like it’s
locked, but it’s not. It keeps cats and toddlers away, but not much else. Another good example would be that the restaurant uses
kitchen utensils that have been withdrawn because they are dangerous.

The fix
We live in a constantly changing world, and people often make mistakes. This means we can no longer fire and forget our
products. Although our product should be bulletproof, maybe some libraries we use is not. One solution is to monitor product
and library updates and update them whenever possible. Getting rid of unused libraries and functionalities also helps a lot. It is
also good practice to automate this task as part of the release pipeline. Read more of automated security testing from Antti’s
blog post.

The restaurant should somehow try to automate the maintenance procedures. They should have a list of the tools they use and
some kind of communication channel to the manufacturer so that information about the tools gets to the restaurant. The
inspection of locks and other equipment should also be done regularly using a checklist.

Identification and Authentication Failures (A07:2021).

Authentication problems revolve very strongly around the fact that a user does not have the right to do the actions that they do.
Whether it happened by accident or on purpose. This could happen when the system mixes user IDs or sessions, gives too many
rights to some users or fails to remove rights when needed. Also allowing brute forcing will usually lead to unauthenticated
actions.

Imagine if one customer places an order, picks it up, drives away and the next customer can buy at the expense of the previous
customer. It would also be problematic if one customer could repeatedly ask the cashier about the companies that have an
account in the restaurant in order to get their own purchases to a company’s account. If drive-through customer orders are
mixed, we are talking about identification failures. The mixing of purchase transactions would also be worrisome.

The fix
In order to improve the quality of software, a secure software development life cycle should be used. Especially the test
automation part in this case. Users should not be able to perform actions for which they are not authorized.

The drive through restaurant in our example should improve the process so that customers’ orders are not mixed up.
Authentication methods should also be used to place the order with the right customer. Cashiers should also be trained against
customers who try to trick someone else into paying for their order.
Software and Data Integrity Failures (A08:2021).
Integrity failures mean that we cannot fully trust the data, library or software we have. Has someone changed the resource we’re
loading or the libraries we’re using? What about our own source code? Is the data intact and not manipulated somehow? Have
our secrets been revealed to users, perhaps through serialization errors?

Let’s imagine that the order process works internally with pieces of paper. If the kitchen doesn’t pay attention to the origin of the
order papers, someone can slip the order under the kitchen door and write on the order that the food should be delivered
through the back door, no questions asked. Another breach of integrity would be if the cashier blurted out all the restaurant’s
secrets to the customer, whether they asked or not.

The fix
We should somehow try to raise the trust factor of our data and libraries. We could scan the products we use for common
vulnerabilities and fix them when patches are available. We should also enforce digital signatures to ensure that updated
information and code are only installed from trusted sources.

In our example, shaking up the cash register and kitchen staff would be in place. They shouldn’t rely on random order notes in
the kitchen. especially if they are found in suspicious places like the floor. Also, the cashier should not leak or overflow
information to a random customer but stick strictly to taking orders.

Security Logging and Monitoring Failures (A09:2021).

When we don’t have a complete view of what is happening in our application, then we have a logging and monitoring risk at
hand. Without good logging and monitoring, we use our software more or less blindly. How do we find out about unauthorized
access or that our software is down due to a traffic spike? It’s also pointless to produce errors that no one can use or understand.

Let’s assume that our restaurant would not properly monitor what is happening. They do not have cameras in the driving lane
and the purchase transaction is monitored only with the minimum amount required by law. The restaurant would have great
difficulty in monitoring which products are sold and developing its business accordingly. There would also be a lack of
communication. For example, if the kitchen makes a mistake and prepares the wrong product, the cashier just shouts “ERROR”
without saying what went wrong.

The fix
When we use our services and applications, we should have a good view of how they work and who uses them with what rights.
Tracking should be used to provide insight into the status of our services. Is it healthy, struggling or down. Logging can be also
used to detect strange anomalies and suspicious user actions.

Logging and monitoring

Surveillance cameras should be added to the driving lane to detect vandalism and abuse. Purchase transactions should also be
recorded at a level that enables the daily business to be run. Not just to the level required by law. The cash register should also
increase communication with the kitchen so that possible errors are understood, and corrective measures are implemented.

Server-Side Request Forgery

Server-side request forgery (SSRF) occurs when the server fails to validate the user-supplied URL to an external resource. A bad
request can go to some third-party service or local file system with extended permissions.

Assume that the customer could somehow change the behavior of the kitchen staff when making a regular order. If the kitchen
staff blindly follows the order, they could be told to pick up the ordered steak from the more expensive restaurant next door. The
steak is then paid for cheaper and the restaurant loses money. It would also be bad if a customer in the driving lane directs the
payment request to the next customer in line and speeds away.

The fix
The server must sanitize all input, perhaps use whitelists for secure connections, should not send raw responses to clients (may
contain something useful to attacker), and use firewall rules to prevent unintended connections. This should give us better
control over what the user is doing.

In our example scenario, the restaurant’s kitchen staff must confirm the request made to the kitchen. If a steak was requested
from the restaurant next door, the request should set off alarm bells in the heads of the kitchen staff. Regarding the redirection
of the payment request. The cashier does not have to accept the current customer’s comment “the next customer in line pays”.
Importance of Mobile App Security
Developers understand the importance of mobile app security, but this is not universally understood. Beyond a rising rate of
mobile fraud, there are several other reasons that financial institutions should take mobile app security seriously and commit to
developing a comprehensive strategy.

Consumers need to be wary of the information they disclose and the data they download when surfing the internet, but business
professionals need to be vigilant as well. Mobile devices are almost always on, always nearby you, and store astounding amounts
of personal information as well as sensitive data and documents. This can make them a treasure-trove for attackers.

Mobile apps may be presumptuous in the permissions they ask for. Why might a weather app need access to your camera or
microphone for example? And might an attacker find a vulnerability in that app that grants them access to the camera or
microphone in order to conduct industrial espionage?

Mobile App Security Threats

Mobile applications connected to business brands are often targeted by fraudsters to either exploit their customers, their
customers’ children, or attack the business itself. Should a mobile malware attack target a user’s device, the consequences could
include:
• Account takeover
• Stolen login credentials
• Stolen and resold credit card details
• Unauthorized access to business networks
• Identity theft
• The iOS or Android device could spread malware to other devices
• SMS messages could be copied and scanned for private information

Benefits of Mobile App Security

Mobile applications generate a tremendous amount of data about us and our lives. So, ensuring apps create and use this
information in a secure way is paramount. Otherwise, insecure applications are an easy route for a malicious act to steal and sell
your personal information.

In addition, there are other mobile solutions that can deliver significant benefits.

• Identity Verification
Identity verification helps prevent an attacker from stealing users’ identities and signing up for accounts under their
name. A robust identity verification process validates that the user is who they say they are and helps prevent an
attacker from committing fraud.
• Strong Authentication
Account takeover is a common problem, and passwords are quickly becoming obsolete. Due to large data breaches of
the last ten years, many username password combinations are already available for sale on the Dark Web. Strong
authentication methods ensure that only legitimate users are accessing their accounts and attackers can’t log-in for
nefarious purposes.
• Biometrics
Biometrics is a secure and convenient way to log-into mobile apps using data derived from your own body. There is no
fool-proof way to determine who is entering a password. The app developer can only determine whether the password
entered matches the password key in the back-end of the system. Biometrics includes an additional indicator of trust,
because it validates the individual offering the biometric sample for verification. Because the fingerprint, face
recognition, or iris scan is presented live and connected to the in-the-flesh user.

Mobile App Security Best Practices

The best practices for counteracting mobile malware and establishing a strong mobile application security strategy differ
depending on whether we are discussing consumers or businesses.

Business Best Practices

Businesses have multiple ways to reduce their risk of mobile attack and data breaches, including:

• Deliver Digital Security Training: Train your team to recognize security issues and avoid risky behavior, spot phishing, and
other cybersecurity strategies. Then keep their skills sharp with unannounced test phishing emails, texts, and other
communications. They should appear in all ways like a typical phishing message, but if the employee clicks, they are
automatically registered for the data security training module. Verizon reported that the majority of phishing attempts
on Mobile are SMS messages and social messaging, as opposed to email, so it is important to vary the phishing medium
as well as the content.
• Acceptable Use Policy: It is valuable for businesses to publish a clear and comprehensive acceptable use policy for
mobile devices that will contain or access business data. Prohibit employees from downloading apps from third-party
 app stores and establish other security best practices in writing. In addition, you could create an app-vetting process to
formally review and select appropriate and secure applications for your team.
• Proactively Monitor for Rogue Apps: Regularly search both legitimate and illegitimate app platforms for any apps that
bear your organization’s name, logo, or messaging. Contact the platform to remove any rogue apps as quickly as possible.
• Deploy a Mobile Security Suite: The OneSpan Mobile Security Suite includes a large set of essential security features,
including mobile app shielding.
• Ensure Security Best Practices: Each application should be developed with security in mind. Ensure your developers are
familiar with mobile app security best practices and frameworks such as the OWASP Mobile Top 10. From there, conduct
regular automated mobile app security testing throughout the SDLC as well as periodic, deeper penetration testing.
Finally, deploy an additional layer of security, App Shielding, to protect the app at runtime and in potentially hostile (out
of date, insecure phone) environments that put the app at risk.