Cybersecurity Studies-3 (Application Security)

8 min readDec 2, 2023

InfoSec Domains Part 3 — Application Security

INFOSEC DOMAINS

3. Application Security

Application security, often abbreviated as “AppSec,” refers to the measures and practices designed to protect software applications from security threats and vulnerabilities throughout the development and deployment lifecycle.

Security is an important part of any application that encompasses critical functionality. This can be as simple as securing your database from attacks by nefarious actors or as complex as applying fraud processing to a qualified lead before importing them into your platform. ²

High availability (HA) is a critical aspect of application security, ensuring that applications remain accessible and operational even in the face of various challenges, including hardware failures, network issues, or security incidents.

# Secure Software Development Life Cycle (SDLC):

Software Development Lifecycle (SDLC) describes how software applications are built. It usually contains the following phases:

Requirements gathering
Analysis of the requirements to guide design — Product owner, Product manager, Business Analyst, CTO
Design of new features based on the requirements- System Architect, UI/UX design
Development of new capabilities (writing code to meet requirements). Front-end Developer, Back-end Developer
Testing and verification of new capabilities — confirming that they do indeed meet the requirements. Solutions Architect, QA Engineer, Tester, DevOps
Deployment of the new project. Data Administrator, DevOps
Maintenance and evolution of these capabilities once the release goes out the door ². Users, Testers, Support Managers

# Security Testing:

Dynamic Application Security Testing: Penetration Testing. DAST works by simulating automated attacks on an application, mimicking a malicious attacker. This “black box” testing looks at an application from the outside in, examines its running state, and observes its responses to simulated attacks made by a testing tool. An application’s responses to these simulations help determine whether the application is vulnerable and could be susceptible to a real malicious attack.⁹ Semgrep, CODETHREAT, SonarQube, Checkmarx
Static Application Security Testing: Static application security testing (SAST), or static analysis, is a testing methodology that analyzes source code to find security vulnerabilities that make your organization’s applications susceptible to attack. SAST scans an application before the code is compiled. It’s also known as white box testing.⁸ PortSwigger, Netsparker, Acunetix, nuclei

# Dependency Scanning:

Scanning third-party libraries, frameworks, and dependencies for known vulnerabilities. This helps ensure that the application doesn’t include components with security flaws.

# Web Application and API Protection (WAAP and WAFs):

Implementing WAFs to filter and monitor HTTP traffic between a web application and the Internet. WAAP adds to the WAF capabilities by securing APIs. WAAP and WAFs help secure applications by filtering malicious traffic and requests, which could be used to steal user credentials or exploit application vulnerabilities. ¹

# Incident Response and Monitoring:

Logging and Monitoring: Implementing robust logging mechanisms to capture security events and anomalies. Monitoring logs can help detect and respond to potential security incidents.
Incident Response Plan: Having a well-defined incident response plan to efficiently address security incidents and minimize the impact on the application and its users.

# Compliance with Standards:

Ensuring that the application adheres to relevant regulatory requirements and industry standards, such as GDPR, HIPAA, or PCI DSS.

# Security Patching and Updates

# IDOR (Insecure Direct Object References):

Insecure Direct Object References (IDOR) occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability attackers can bypass authorization and access resources in the system directly, for example database records or files. IDOR vulnerabilities are most commonly associated with horizontal privilege escalation, but they can also arise in relation to vertical privilege escalation. ¹⁰

Generally, IDOR attacks are of two types:

Body Manipulation. Attackers modify the value of a checkbox, radio buttons, and form fields. This lets them access information from other users with ease.
URL Tampering. The URL is modified at the client’s end by tweaking the parameters in the HTTP request. HTTP verbs GET and POST are typically vulnerable to a URL tampering IDOR attack. ¹¹

IDOR (Insecure Direct Object References) ¹¹

Here are ways to avoid IDOR vulnerability:

Avoid Exposing Direct Object References: Instead of requiring the references in the URL, use the information already present in the user’s session on the server to locate the resources to serve. For example, in the www.example.com/profile/3032 route implementation we just reviewed, if the users are allowed to access only their profile, we can use the logged-in user’s ID in the session to locate it, thus eliminating the need for passing id as a URL parameter. ¹²
Use an Indirect Reference Map: If it is not possible to avoid exposing the references to objects in the URL, as explained earlier, the indirect reference map technique is helpful. The idea behind it is to substitute the sensitive direct internal reference in URL parameters or form fields with a random value that is difficult to predict (such as a GUID) or specific only to the logged-in user (such as sequential values per user or session).¹² Let’s go back to the credit card example. Instead of using direct references in the URL www.example.com/credit/profile/id#12, use indirect references www.example.com/c/ab. Then, refer to the indirect reference map to look for the actual reference. This way, direct references containing users’ credit card information will not be exposed.¹¹
Validate User Access: This defense mechanism addresses the primary issue causing the vulnerability: an insufficient or missing access check. First, never rely only on client-side validations for access control, because an attacker can easily circumvent those.¹² At the very least, the application should perform a Syntactic Validation to verify suspicious inputs. The application should establish criteria for incoming input, and if it doesn’t meet expectations, reject the value.
Here are some criteria you can apply to your application:
Minimum or maximum length
Minimum or maximum bounds (for numeric values)
Acceptable characters
Data Type (e.g. string, date, integer, rational, etc.) ¹¹

# Port Security:

Close or disable unnecessary ports and services.
Avoid using default ports
Port knocking is a security technique where a sequence of connection attempts to specific ports must be made before access is granted.

# Authentication and Authorization

Authentication means confirming the identity of the user for them to be allowed to access the application. Authorization, on the other hand, is granting or restricting them access to certain features or resources of the application.

#Copy-Pasting Code

# Input Validation:

In software development, input validation is often considered the first defense against various security vulnerabilities. It’s a mechanism that helps ensure only properly formatted data enters a system, thereby reducing the risk of unauthorized data manipulation and injection attacks. ⁴ Can be used against Cross Site Scripting (XSS), SQL Injection, Remote and Local File Inclusion.

Syntactic Validation: Syntactic validation should enforce the correct syntax of structured fields (e.g. SSN, date, currency symbol).
Semantic Validation: Semantic validation ensures the data makes sense in a specific business context. (e.g. start date is before the end date, price is within the expected range).
Block List (Blacklist): It is a common mistake to use block list validation to try to detect possibly dangerous characters and patterns like the apostrophe character, the string 1=1, or the <script> tag. The block list approach is generally not recommended as it is easy for attackers to bypass such filters.
Allow List (Whitelist): Allow list validation involves defining exactly what is authorized, and it leaves everything else as not authorized. For example, if a field should only contain alphabetical characters, then an allow list would specify that only A-Z and a-z are acceptable.
Validating free-form Unicode text: Free-form inputs, such as text, have a reputation of being the most difficult to validate, as there’s such a wide range of possible variables. To validate free-form UNICODE inputs, you should practice normalization to ensure no invalid characters are present. Create an allow-list for acceptable character categories, such as Arabic or Cyrillic alphabets. You can also create allow-lists for individual characters, like the apostrophe in a name field.⁶
Regular Expression Validation: Basically, a regular expression is a pattern describing a certain amount of text. Regular expressions are used to validate structured data. For example, a regular expression could be used to validate email formats. This pattern describes an email address:

\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}\b'

Client-Side Validation vs Server-Side Validation: Be aware that any JavaScript input validation performed on the client can be bypassed by an attacker, who can disable JavaScript or use a Web Proxy. Make sure that any input validation performed on the client is also performed on the server. ⁵ Server-Side Validation ensures data integrity by checking the data on the server before it is handled by the application. We should use a combination of both Client-Side and Server-Side Validation to ensure data integrity.
File Upload Validation: Ensures the filename uses an expected file type and size. Uploaded files should be analyzed for malicious content (anti-malware, static analysis, etc.). When the file is uploaded to the web, it’s suggested to rename the file on storage. The user shouldn’t be able to dictate where the file is stored, either.
Preventing XSS and Content Security Policy: All user data controlled must be encoded when returned in the HTML page to prevent the execution of malicious data (e.g. XSS). For example <script> would be returned as <script>.URL Encoding.
Email Address Validation: This includes both syntactic and semantic validation. Semantic validation ensures that the email address exists and can receive emails. The most common way to do semantic validation is to send an email to the user, and require that they click a link in the email, or enter a code that has been sent to them. Syntactic validation ensures the email follows a specific format. The format of email addresses is defined by RFC 5321 and is far more complicated than most people realize. As an example, the following are all considered to be valid email addresses:

"><script>alert(1);</script>"@example.org
user+subaddress@example.org
user@[IPv6:2001:db8::1]
" "@example.org

Enjoyed this post? If yes, please show some appreciation by clicking on the “clap” button. Fun trivia — you can hit it up to 50 times! It helps the content reach out to more like-minded people.

Please share your thoughts and feedback in the comments below. This will help me improve and also inspire me to create more.

I try to publish regularly on Medium. Follow this account to receive similar content in future, and click here to get each post directly in your email. You can find me on Linkedin and Github as well.

Links: