Application Security Fundamentals

Question 1

What is application security?

Answer 1

The primary defense in application security involves integrating security throughout the entire software lifecycle, from planning and development to implementation. Approaches like DevSecOps build on the Secure Software Development Lifecycle (SSDLC) to integrate security at each phase, leveraging DevOps’ iterative automation processes and fostering a culture of collective security ownership. Key elements include threat modeling, secure coding practices, and automated security testing. These measures reduce the attack surface before deployment. Post-deployment, continuous monitoring, regular patching, incident response planning, and compliance checks ensure any residual vulnerabilities are promptly addressed.

It includes:

1. Secure Coding: Writing code to avoid vulnerabilities like SQL injection and XSS.
2. Threat Modelling: Identifying potential threats and designing defences.
3. Vulnerability Testing: Using tools like SAST, DAST, and IAST to find and fix vulnerabilities.
4. Patch Management: Regularly updating the application and its components.
5. Authentication & Authorisation: Ensuring proper identity verification and access control.
6. Encryption: Protecting data in transit and at rest.
7. Logging & Monitoring: Tracking and analysing application activity for signs of threats.
8. Incident Response: Planning for and managing security breaches.
9. Compliance: Adhering to relevant regulations and standards.

Application security is crucial to prevent breaches, data loss, and unauthorised access.

Question 2

Why is application security important?

Answer 2

Applications security is important because:

• Guaranteeing the security of sensitive information
• Developing user trust and boosting reputation
• Mitigating the potential for attacks

Question 3

What is the difference between DevSecOps and a Secure Software Development Lifecycle (SSDLC)?

Answer 3

DevSecOps vs. SSDLC:

• SSDLC (Secure Software Development Lifecycle):
  
  • Approach: Structured, sequential process integrating security at every stage (planning, design, development, testing, deployment, maintenance).
  • Focus: Formal security practices, often more manual and phase-driven.
  • Methodology: Traditional, linear with defined phases.
• DevSecOps:
  
  • Approach: Iterative, continuous integration of security within DevOps pipelines.
  • Focus: Automation, speed, and collaboration; security is everyone’s responsibility.
  • Methodology: Agile, automated, and culture-driven, aligning with continuous delivery models.

Comparison:
- SSDLC is more formal and phase-driven, often with manual processes.
- DevSecOps operationalizes SSDLC principles in a continuous, automated, and collaborative environment, suited for fast-paced DevOps cultures.

Question 4

What are the common threats for applications?

Answer 4

1. SQL Injection: Malicious SQL statements are injected into an entry field to manipulate the database.
2. Cross-Site Scripting (XSS): Attackers inject malicious scripts into web pages viewed by other users, leading to data theft or session hijacking.
3. Cross-Site Request Forgery (CSRF): Forces a user to execute unwanted actions on a web application where they are authenticated, potentially leading to unauthorized actions.
4. Security Misconfiguration: Improperly configured security settings, such as default passwords or open ports, leaving applications vulnerable to attack.
5. Buffer Overflow: Occurs when more data is written to a buffer than it can hold, potentially allowing attackers to overwrite memory and execute arbitrary code.

Question 5

What is cross-site scripting (XSS)?

Answer 5

Cross-Site Scripting (XSS) is a type of security vulnerability typically found in web applications. It occurs when an attacker injects malicious scripts (usually JavaScript) into content that is delivered to other users. The script can then be executed in the context of the victim’s browser, leading to various malicious activities such as data theft, session hijacking, or defacement of the website.

The Three Most Common Types of XSS:

1. Stored XSS (Persistent XSS):
   
   • Description: The malicious script is permanently stored on the target server, such as in a database, forum post, or comment field. When a user views the infected content, the script is delivered and executed in their browser.

Example: An attacker posts a comment containing malicious script on a forum. Every time someone reads that comment, the script runs in their browser.

2. Reflected XSS (Non-Persistent XSS):
   
   • Description: The malicious script is reflected off a web server, usually in error messages, search results, or other responses that include user input. The script is not stored but is instead immediately delivered to the victim.

Example: An attacker sends a link with a malicious script embedded in the URL to a user. When the user clicks the link, the script is reflected off the server and executed in their browser.

3. DOM-Based XSS:
   
   • Description: The vulnerability is in the client-side code (JavaScript), where the script is executed directly by modifying the Document Object Model (DOM) of the page. This type of XSS occurs when the client-side script processes user input and updates the DOM without proper validation.

Example: An attacker manipulates the URL or other inputs that are processed by client-side JavaScript, which in turn dynamically updates the page content and executes the malicious script.

Summary:
- Stored XSS: Malicious script is stored on the server and delivered to users when they view the content.
- Reflected XSS: Malicious script is reflected off the server and delivered via a request (e.g., a URL).
- DOM-Based XSS: Malicious script is executed by manipulating the client-side DOM directly, without involving the server.

Question 6

What are the various types of application misconfigurations?

Answer 6

Some of the major causes of application vulnerabilities include:

• Incorrect file permissions or ownership settings.
• Inadequate hardening of applications and systems.
• Insecure databases, particularly concerning access rights.
• Outdated or unpatched software.
• Misconfigurations or resets due to updates.
• Debugging information exposing sensitive data.
• Insufficient testing of application code, leading to security gaps.

Question 7

What is SQL injection (SQLi)?

Answer 7

SQL Injection is a web security vulnerability where an attacker inserts malicious SQL code into a query, allowing them to manipulate the database, access unauthorised data, or perform other harmful actions.

Types of SQL Injection:

1. Classic SQL Injection:
   
   • Directly manipulates SQL queries by injecting malicious input through user input fields.
2. Blind SQL Injection:
   
   • The attacker cannot see the results of the SQL injection directly but infers information based on the web application’s responses (e.g., true/false responses).
3. Error-Based SQL Injection:
   
   • Exploits error messages from the database to gather information about the structure of the database.
4. Union-Based SQL Injection:
   
   • Combines results from multiple SELECT statements into a single result, allowing attackers to extract data from different tables.
5. Time-Based SQL Injection:
   
   • Uses SQL commands that cause a delay, allowing the attacker to infer information based on the time taken to respond.

Question 8

What is buffer overflow?

Answer 8

Buffer Overflow is a security vulnerability that occurs when more data is written to a buffer (a temporary data storage area) than it can hold. This can lead to adjacent memory areas being overwritten, potentially allowing an attacker to execute arbitrary code or crash the system.

Types of Buffer Overflow:

1. Stack Overflow:
   
   • Occurs in the call stack when more data is written to a stack buffer than it can handle, often leading to control flow hijacking.
2. Heap Overflow:
   
   • Happens in the heap memory area, where excess data overwrites adjacent memory, potentially corrupting data or allowing code execution.
3. Unicode Overflow:
   
   • Exploits vulnerabilities in handling Unicode characters, often leading to buffer overflows due to incorrect assumptions about character size.
4. Integer Overflow:
   
   • Occurs when an arithmetic operation results in a value larger than the allocated space can handle, potentially leading to buffer overflows if the value is used in memory allocation or indexing.

Question 9

What is cross-site request forgery (CSRF)?

Answer 9

Cross-Site Request Forgery (CSRF) is a web security vulnerability where an attacker tricks a user into performing an unwanted action on a web application in which they are authenticated. For example, the attacker could craft a malicious link or form that, when visited or submitted by the victim, causes the victim’s browser to make a request to the application, performing actions like changing account details or making a purchase without the user’s consent.

Mitigations:

1. CSRF Tokens:
   
   • Include unique, unpredictable tokens in requests that change state (e.g., form submissions). The server checks for the presence and validity of the token before processing the request.
2. SameSite Cookies:
   
   • Configure cookies with the SameSite attribute, which restricts how cookies are sent with cross-site requests, helping to prevent CSRF attacks.
3. Double Submit Cookies:
   
   • Include a CSRF token in both a cookie and as a request parameter, with the server validating that both tokens match.
4. Referer and Origin Header Checks:
   
   • Validate the Referer or Origin headers in requests to ensure they come from trusted sources.
5. User Interaction Verification:
   
   • Require additional confirmation for critical actions, such as password changes, to ensure they are intended by the user.

Question 10

What is the OWASP Application Security Verification Standard (ASVS) used for?

Answer 10

It was developed with the following objectives:

• As a metric: To provide application developers and owners with a benchmark to assess how trustworthy their applications are.
• As guidance: To offer developers clear instructions on which security controls to implement to meet security requirements.
• For procurement: To serve as a foundation for specifying application security verification requirements in contracts.

Question 11

What are the best practices for incorporating secure frameworks and/or libraries in applications?

Answer 11

Best practices for using secure frameworks and libraries include:

• Reuse: Only utilise frameworks and libraries from actively maintained sources that are widely adopted by other applications.
• Catalogue: Maintain an inventory of all third-party code libraries as they are integrated.
• Check: Regularly verify that all code components and libraries are up to date, using dependency-checking tools to identify and address known vulnerabilities.
• Reduce: Minimise vulnerabilities and the attack surface by reusing only the necessary portions of code required for specific functions and behaviour.

Question 12

What scenarios are application hardening techniques typically used for?

Answer 12

Application hardening techniques are commonly employed for the following purposes:

• Protecting against reverse-engineering of the application back to its source code.
• Preventing the inspection of internal values, as well as monitoring or tampering with the application.
• Ensuring the application can securely operate in zero-trust environments.
• Safeguarding data and sensitive information.

Question 13

What are the typical application hardening techniques?

Answer 13

Code Obfuscation (Including Binary Code Obfuscation)

• Description: Obfuscation makes source code and binary code difficult to understand for anyone attempting to reverse-engineer the application. It alters variable names, control structures, and logic flows while maintaining functionality.
• Binary Code Obfuscation: Specifically targets compiled binary files, making it harder for attackers to decompile and analyse the code or retrieve sensitive information.

White Box Cryptography

• Description: Involves encrypting data in a way that remains secure even if the attacker has full visibility of the algorithm, key, and execution environment. This method ensures that sensitive cryptographic operations are difficult to extract or manipulate, even in compromised environments.

Anti-Debugging

• Description: Techniques that detect and prevent the use of debugging tools on an application. This can include checks that look for attached debuggers or the presence of breakpoints, and, if detected, can either terminate the application or change its behaviour to prevent analysis.

Anti-Tampering

• Description: Measures designed to detect and respond to any attempt to alter the application’s code or behaviour. This may involve verifying the integrity of the code, and if tampering is detected, the application can either terminate or restrict access to critical features.

Integrity Checkers

• Description: Tools or routines that periodically verify the integrity of application files, code, or configuration settings. If any unauthorised modifications are detected, the application can respond by restoring the original state, alerting the user, or shutting down.

Anti-Rooting

• Description: Security measures that detect if an Android device has been rooted (i.e., granted superuser privileges), which could allow attackers to bypass security controls. If rooting is detected, the application may refuse to run or limit functionality.

Jailbreak Protection

• Description: Similar to anti-rooting, jailbreak protection is designed to detect if an iOS device has been jailbroken (i.e., modified to remove Apple’s restrictions). Jailbroken devices pose a higher security risk, and applications often restrict functionality or refuse to run on such devices.

Runtime Application Self-Protection (RASP)

• Description: RASP embeds security into the application itself, monitoring its behaviour during runtime and providing real-time protection. It can block attacks as they occur, based on behavioural patterns and environmental conditions.RASP Features:
• Anti-Screen Readers: Prevents attackers from using screen readers or accessibility services to extract sensitive information displayed on the screen.
• Anti-Keylogging: Protects against keylogging attacks by preventing third-party applications from capturing sensitive data entered via the keyboard.
• Device Binding: Ensures the application can only run on the device it was originally installed on, preventing attackers from transferring the app to another device for analysis or exploitation.
• Anti-Hooking: Blocks attempts by attackers to attach themselves to the application and execute calls during its runtime, preventing them from interfering with the application’s processes.
• Anti-Emulator: Detects and prevents the application from running in emulated or virtual environments, where attackers might trace its operations to discover vulnerabilities or reverse-engineer the application.

Question 14

What are the factors you should consider when trying to secure a database?

Answer 14

Database security must consider the following factors:
- the data stored within the database,
- the database management system,
- any applications linked to the database (such as a web server),
- the database server or service,
- the underlying hardware (whether physical or part of a virtual environment),
- and the network infrastructure used to access the system.

Question 15

What are the common mitigation techniques for application security threats?

Answer 15

Common mitigation techniques for application security threats include the following:

1. Prepared Statements (SQL Injection Prevention): SQL injection attacks can be mitigated by using prepared statements (also known as parameterised queries). This ensures that user input is treated as data and not executable code, preventing attackers from manipulating SQL queries.
2. Encoding and Escaping: Encoding and escaping are essential to prevent malicious data from being interpreted as executable code. For instance, encoding user inputs in web applications ensures that special characters are treated as plain text rather than commands. This is crucial for preventing various injection attacks.
3. Input Validation: Proper input validation is a fundamental security measure. There are two approaches:
   
   • Whitelisting: Only allowing specific, predefined inputs that are known to be safe.
   • Blacklisting: Blocking known malicious or suspicious inputs. Whitelisting is generally more secure, as it reduces the risk of missing new or unknown malicious inputs.
4. Cross-Site Scripting (XSS) Mitigation: To defend against XSS attacks, a combination of whitelisting and escaping characters can be used to sanitise user input. Additionally:
   
   • Content-Security Policy (CSP): A CSP helps mitigate XSS attacks by controlling what resources a web page is allowed to load (e.g., scripts, styles). By specifying which sources are trusted, CSP prevents the browser from executing unauthorised or malicious scripts.
   • HTTP-only Cookies: Setting cookies with the “HTTP-only” flag ensures that they cannot be accessed via JavaScript, reducing the risk of theft through XSS attacks.
5. HTTPS and PKI Infrastructure: Using HTTPS (via SSL/TLS) ensures secure communication between the client and server by encrypting HTTP content, URLs, header information, and cookies. This prevents man-in-the-middle (MITM) attacks and ensures that sensitive data is protected. Public Key Infrastructure (PKI) helps verify the identity of websites, organisations, and individuals, further securing the connection.

By combining these techniques, applications can be better protected against a wide range of security threats, including SQL injection, XSS, and man-in-the-middle attacks.

Question 16

What is an X.509 certificate? (Key pairs and signatures)

Answer 16

An X.509 certificate is a digital certificate that includes a public key, a digital signature, and important details about the identity of the certificate holder and the issuing certificate authority (CA). The public key is part of a key pair, with the private key kept secure by the certificate holder.

X.509 Certificate Overview:

• Key Pair: An X.509 certificate contains a public key, while the corresponding private key is kept secure by the certificate holder.
• Digital Signature:
  • The certificate includes a digital signature, which is a hash of the document encrypted using the private key.
  • A trusted certificate authority (CA), such as SSL.com or Verisign, signs the certificate, verifying the identity of the certificate holder.
• Public/Private Key Functions:
  
  • The owner of the private key can digitally sign documents, and anyone with the matching public key can verify these signatures.
  • Only the private key owner can decrypt messages that have been encrypted using the public key by a third party.
• Structure of X.509 Certificate:
  
  • The certificate includes specific information, such as:
    
    • Issuing Certificate Authority (CA): Identifies who issued the certificate.
    • Subject: The entity (individual, organisation) to whom the certificate is issued.
    • Certificate Version: Defines the version of the certificate format.
    • Signature ID: Identifies the cryptographic algorithm used.
    • Validity Period: The time frame during which the certificate is valid and trusted.

Common uses of X.509 certificates include:

• SSL/TLS and HTTPS for secure and authenticated web browsing
• Signed and encrypted emails using the S/MIME protocol
• Code signing for verifying software authenticity
• Document signing for legal and official verification
• Client authentication
• Government-issued electronic identification (e-ID).

This structured approach allows for secure communication, data encryption, and identity verification, commonly used in SSL/TLS for securing websites.

Question 17

What are the mitigation techniques for defending against IoT system attacks?

Answer 17

The National Institute of Standards and Technology (NIST) outlines four key best practices for developing secure IoT-based systems:

• Use of RFID tagging: Helps combat counterfeit devices by assigning unique identifiers to devices. RFID tags can be activated by readers to transmit data within predefined bandwidth channels.
• Changing default credentials: Devices should offer secure methods for updating default credentials, such as user-friendly GUI tools and password randomisation, to enhance security.
• Manufacturer Usage Description (MUD) specification: Allows manufacturers to define traffic patterns and limit communication between sources and destinations, thereby reducing the system’s vulnerability to attacks.
• Secure upgrades: IoT devices often lack the secure upgrade systems used in other domains (e.g. operating systems, software, mobile apps). Manufacturers should optimise IoT firmware upgrade architectures to enable more secure and automated upgrade processes.

Question 18

What are the benefits of application security penetration testing?

Answer 18

The benefits of application security testing include:

• Risk Mitigation: It helps identify and address potential security risks, ensuring that the software meets end-user requirements without compromising security.
• Proactive Threat Identification: Security testing can be conducted using a white-hat approach to anticipate and counteract potential attack methods used by malicious actors.
• Infrastructure Insights: Testing can uncover vulnerabilities or breaches in the broader network and IT infrastructure, helping to strengthen overall security.
• Responsiveness Evaluation: Security testing allows organisations to assess how well individuals, teams, and the organisation respond to security breaches and vulnerabilities detected during testing.
• Compliance with Standards: Testing ensures that the software meets industry standards, such as ISO 27001, and complies with legal requirements, which is especially critical in high-security environments.

Question 19

What are some common web application security vulnerabilities?

Answer 19

Some of the most common web application vulnerabilities include:

• Insecure Data Storage: Storing sensitive data without proper encryption or protection, making it easier for attackers to access and exploit.
• Poor Authentication and Authorisation: Weak or poorly implemented authentication and authorisation mechanisms can allow unauthorised users to gain access to sensitive areas of the application.
• Weak Cryptography: Using outdated or inadequate cryptographic methods can leave data vulnerable to interception and manipulation by attackers.
• Vulnerability to Tampering: Applications that don’t properly validate input or protect against data manipulation are susceptible to tampering, where attackers alter data to exploit the system.
• Poor Quality Code: Code that has not been thoroughly reviewed or tested can introduce security flaws, making the application more prone to attacks.
• Vulnerability to Reverse Engineering: Applications that lack obfuscation or sufficient security measures can be reverse-engineered by attackers to discover vulnerabilities or steal sensitive information.

Question 20

What are the stages of app penetration testing?

Answer 20

The stages of application penetration testing typically include the following:

1. Threat Modelling: Identifying and prioritising critical applications to ensure the testing is tailored to the organisation’s specific security needs, resulting in detailed and relevant reports.
2. Reconnaissance: Gathering as much information as possible about the application using various tools. This stage helps testers understand the system and identify potential points of attack.
3. Vulnerability Scanning: Using manual or automated processes to scan the application for misconfigurations and known vulnerabilities. Fuzzing may also be used to detect issues by sending random or invalid data inputs to the system.
4. Developing Exploits: After identifying vulnerabilities, testers attempt to manually exploit the flaws to assess the potential damage and impact, simulating real-world attack scenarios.
5. Develop Guidelines: Penetration testing guidelines are created for security teams, software developers, and analysts. These guidelines focus on addressing the vulnerabilities discovered during testing and recommend effective remediation strategies.
6. Remediation and Verification: After vulnerabilities are fixed, they are re-tested to ensure they have been properly remediated and verified according to the organisation’s compliance and security procedures.

Question 21

What are the various techniques used in application penetration testing?

Answer 21

1. Fuzzing: This technique involves inputting large amounts of random or unexpected data (referred to as fuzz) to identify vulnerabilities. Fuzzing is often used alongside:
   
   • White Box Testing: Full knowledge of the application’s code.
   • Black Box Testing: No prior knowledge of the internal structure.
   • Grey Box Testing: Partial knowledge of the application’s internals.
   Fuzzing is commonly used for testing web APIs and can involve mutation-based or generation-based fuzzing. It is effective in detecting vulnerabilities such as denial-of-service (DoS) attacks, buffer overflows, SQL injection, and cross-site scripting (XSS).
2. Vulnerability Testing: This includes both:
   
   • Dynamic Application Security Testing (DAST): Testing the application in its running state to find vulnerabilities by simulating real-world attacks.
   • Static Application Security Testing (SAST): Analysing the application’s source code or binary for potential security flaws without executing the program.
3. Sandboxing: Involves isolating the application in a controlled environment to safely test for vulnerabilities without risking the production environment. This technique helps assess how the application behaves under attack and prevents the impact from spreading.
4. Keeping Applications Up-to-Date: Ensuring that all software components, libraries, and dependencies are up-to-date is a critical part of penetration testing. Outdated software is more susceptible to known vulnerabilities, so this technique ensures that patches are applied regularly to minimise security risks.

These techniques together provide a comprehensive approach to identifying and mitigating security weaknesses in applications.

Question 22

How does DevSecOps operationalise the fundamental elements of a SSDLC using CI/CD pipelines (automated and iterative processes from DevOps)

Answer 22

Yes, you’re absolutely right! DevSecOps takes the foundational principles of Secure Software Development Life Cycle (SSDLC) and integrates them into an iterative, automated process using CI/CD (Continuous Integration/Continuous Deployment) pipelines.

Here’s a breakdown:

SSDLC (Secure Software Development Life Cycle):
- SSDLC emphasizes building security into every phase of the software development life cycle, from planning and design to coding, testing, and deployment.
- The goal is to ensure that security is not an afterthought but is incorporated into each step of the development process.

DevSecOps:
- DevSecOps extends the traditional DevOps practices by integrating security into the CI/CD pipeline, making security an essential and continuous part of the development and deployment process.
- It emphasizes that security should be the responsibility of everyone involved in development, from developers to operations and security teams.

Operationalizing SSDLC in DevSecOps:
- Iterative and Automated: In DevSecOps, security is not just a one-time step; it’s built into every iteration of the development process. With CI/CD pipelines, every code change (even small updates) passes through automated security checks, such as static code analysis, dynamic testing, and vulnerability scanning.
- Continuous Integration: In CI, developers frequently merge code into a shared repository, and automated security checks (like code quality checks, vulnerability scans, and security unit tests) are applied early in the process.
- Continuous Deployment/Delivery: In CD, code is automatically deployed to production environments, often with additional security checks, such as penetration testing and runtime security monitoring.

Key Concepts in DevSecOps:
1. Shift-Left Security: Security practices are moved earlier in the development cycle (left on the timeline), ensuring vulnerabilities are caught and fixed as early as possible.
2. Automation: Security checks and testing are automated as part of the CI/CD pipeline, ensuring fast feedback to developers and reducing manual intervention.
3. Collaboration: Development, operations, and security teams work together to make security an integral part of the entire development process.

Summary:
- DevSecOps operationalizes the principles of SSDLC by embedding security into the CI/CD pipelines, ensuring that security is continuously applied and iterated upon at every stage of development. This ensures rapid, secure delivery of software while maintaining security standards.