/Get-Ready-For-Pentest-Interview

Interview

Welcome to our Web Penetration Tester Interview Notion page! Here, we've curated a comprehensive resource to help you prepare for your web penetration tester interviews. Whether you're just starting out or looking to advance your career in cybersecurity, this page has everything you need.

Key Sections:

  1. Bugs and Impact: Explore common bugs encountered in web applications and their potential impact on security. From SQL injection to cross-site scripting (XSS), we cover it all.
  2. Detection Phase: Learn about the crucial process of detecting vulnerabilities in web applications. Understand the methods and techniques used by penetration testers to identify security weaknesses.
  3. Prevention Strategies: Discover effective strategies for preventing and mitigating security vulnerabilities in web applications. From secure coding practices to implementing robust authentication mechanisms, we've got you covered.
  4. Tools of the Trade: Explore a curated list of tools commonly used by web penetration testers. From open-source software to commercial solutions, find the right tools to streamline your testing process.
  5. Soft Skills and Interview Preparation: Enhance your soft skills and prepare for the interview process with our collection of resources. From communication skills to problem-solving techniques, we'll help you ace your interview.
  6. Interview Question Types: Get familiar with the different types of questions you may encounter during your web penetration tester interview. From knowledge-based questions to behavioral scenarios, we've prepared you for every step of the interview process.

Start Exploring:

Dive into each section to access detailed information, helpful tips, and valuable resources to boost your confidence and performance during your web penetration tester interviews.

Important Bugs

SQLi

What is SQLi ?

SQL injection (SQLi) is a web security vulnerability that allows an attacker to interfere with the queries that an application makes to its database. This can allow an attacker to view data that they are not normally able to retrieve. This might include data that belongs to other users, or any other data that the application can access. In many cases, an attacker can modify or delete this data, causing persistent changes to the application's content or behavior.

Impact of SQLi ?

A successful SQL injection attack can result in unauthorized access to sensitive data, such as:

  • Passwords.
  • Credit card details.
  • Personal user information.

How to detect SQLi ?

You can detect SQL injection manually using a systematic set of tests against every entry point in the application.

  • Entry Points
    • Headers
      • Cookies
      • User agents
    • Fields
      • name, username, address , …

To do this, you would typically submit:

  • The single quote character ' and look for errors or other anomalies.
  • Some SQL-specific syntax that evaluates to the base (original) value of the entry point, and to a different value, and look for systematic differences in the application responses.
  • Boolean conditions such as OR 1=1 and OR 1=2, and look for differences in the application's responses.
  • Payloads designed to trigger time delays when executed within a SQL query, and look for differences in the time taken to respond.
  • OAST payloads designed to trigger an out-of-band network interaction when executed within a SQL query, and monitor any resulting interactions.

How to prevent SQL injection ( Mitigation Techniques ) :

  • Use prepared statements ( server side )
  • Input validation ( client side )

Tools :

SQLMap , ghauri

Recap :

Let’s recap the lesson

  • SQLi occurs when an attacker can alter SQL query to something new that not supposed to be
  • There are some common SQLi techniques, Union based, Boolean blind, Time blind, etc
  • Each technique works in a case:
    • Union based: when Query is select and the data is shown to users directly
    • Boolean blind: when SQL data is shown to users indirectly
    • Time blind: when nothing is shown to users
  • In Union based injection, order by helps attacker determine number of columns in the select Query
  • In Boolean blind, True and False conditions must be identified, the data should be extracted byte by byte
  • In Time blind, the True and False condition is measured by the time delay for each request
  • In SQLi, the privilege of the user is limited by SQL user that handles the connection
  • In order to pull out data, database names, table names and column names should be known
  • All names (DB, Table, etc) are stored in a database named information_schema
  • No matters what technique is used for SQLi, information_schema always have required data
  • In SQLi, HEX equivalent can be used in strings by 0xHEX (cannot be used in Query syntax)
  • If a target is vulnerable to SQLi, Time based always work, Boolean blind or Union may work or do not
  • SQLMap can be used in order to detect and exploit a SQLi flaws

More reading :

Second-order SQL injection

First-order SQL injection occurs when the application processes user input from an HTTP request and incorporates the input into a SQL query in an unsafe way.

Second-order SQL injection occurs when the application takes user input from an HTTP request and stores it for future use. This is usually done by placing the input into a database, but no vulnerability occurs at the point where the data is stored. Later, when handling a different HTTP request, the application retrieves the stored data and incorporates it into a SQL query in an unsafe way. For this reason, second-order SQL injection is also known as stored SQL injection.

Second-order SQL injection often occurs in situations where developers are aware of SQL injection vulnerabilities, and so safely handle the initial placement of the input into the database. When the data is later processed, it is deemed to be safe, since it was previously placed into the database safely. At this point, the data is handled in an unsafe way, because the developer wrongly deems it to be trusted.

OS Command Injection

What is OS Command Injection ?

OS command injection is also known as shell injection. It allows an attacker to execute operating system (OS) commands on the server that is running an application, and typically fully compromise the application and its data.

Impact of OS Command Injection :

an attacker can leverage an OS command injection vulnerability to compromise other parts of the hosting infrastructure, and exploit trust relationships to pivot the attack to other systems within the organization.

How to detect ?

Test entry points with time delay payloads :

& ping -c 10 127.0.0.1 &

Entry points :

  • Converting an image/Video
  • Calling an external web service
  • Calling a binary

How to prevent ?

  • Validating against a whitelist of permitted values.
  • Input sanitization

Tips :

  • HTTP is an stateless protocol, in the Command Injection, attackers execute commands on a non-interactive shell
  • An interactive shell can be achieved through 2 ways
    • Spawning a shell and bind it on a port in target machine, connecting to it directly (nowadays is impossible, why?)
    • Using a reverse shell forcing target machine to connect back to attacking machine
  • Procedure:
    • Attacker’s machine listens on a port
    • Victim’s machine connects to the port
    • Victim’s spawn a shell
    • Attacker will have the shell
  • A useful site → https://www.revshells.com

Tools :

Commix

Recap :

Let’s recap the Command Injection lesson

  • It happens when unsafe inputs pass through shell without sanitization
  • In BlackBox tests, hackers should fuzz all inputs to detect Command Injection (depends on their methodology)
  • Browsing web applications normally leads to identify suspicious inputs to test
  • The best way to get an interactive shell is reverse shell technique
  • Reverse shell is to force the target machine to connect to the attacker machine and spawn a shell
  • In order to exfiltrate data, Out of Band technique can be used, HTTP and DNS protocols are the first choices

Remote Code Execution

What is RCE ?

  • In other word, the web application evaluates the code without validating it
  • In most cases, eval() function is the cause, but what is it?
  • The eval() function evaluates a string as a code (in most languages, there is a same concept with different function)

Impact of RCE :

Running arbitrary code.

How to Detect :

Test entry points.

How to prevent ?

  • Code Review and Audits
  • Input validation and sanitization

Recap :

Let’s recap the Remote Code Execution lesson

  • RCE happens when a malicious input is passed into the eval function
  • RCE mostly is discoverable by source code review
  • Using some characters such as single quote to break the context is useful
  • Fixing the string is needed to get injected code executed

Server Side Template Injection

What is SSTI ?

Server-side template injection is when an attacker is able to use native template syntax to inject a malicious payload into a template, which is then executed server-side.

Impact of SSTI ?

  • At the severe end of the scale, an attacker can potentially achieve remote code execution, taking full control of the back-end server and using it to perform other attacks on internal infrastructure.
  • Even in cases where full remote code execution is not possible, an attacker can often still use server-side template injection as the basis for numerous other attacks, potentially gaining read access to sensitive data and arbitrary files on the server.

How to detect ?

Perhaps the simplest initial approach is to try fuzzing the template by injecting a sequence of special characters commonly used in template expressions, such as ${{<%[%'"}}%\. If an exception is raised, this indicates that the injected template syntax is potentially being interpreted by the server in some way. This is one sign that a vulnerability to server-side template injection may exist.Server-side template injection vulnerabilities occur in two distinct contexts, each of which requires its own detection method. Regardless of the results of your fuzzing attempts, it is important to also try the following context-specific approaches. If fuzzing was inconclusive, a vulnerability may still reveal itself using one of these approaches. Even if fuzzing did suggest a template injection vulnerability, you still need to identify its context in order to exploit it.

How to prevent ?

  • The best way to prevent server-side template injection is to not allow any users to modify or submit new templates.
  • One of the simplest ways to avoid introducing server-side template injection vulnerabilities is to always use a "logic-less" template engine, such as Mustache.
  • Another measure is to only execute users' code in a sandboxed environment where potentially dangerous modules and functions have been removed altogether.

Tools :

https://github.com/epinna/tplmap

Recap

Let’s recap the Server Side Template Injection lesson

  • If malicious input is passed into template render function, the SSTI will happen
  • Use ${{<%[%'"}}%\\. to trigger an error, it’s likely template injection
  • Use this link for continue the process of vulnerability discovery
  • Use Tplmap to detect and exploit the flaw, in some cases you should alter the payloads (CTF, etc)

Browser APIs

DOM , BOM , CORS , COOKIE , CSP , SOP

BOM

Let’s start with Browser Object Model (BOM)

  • The BOM provides objects that expose the web browser’s functionality
  • Let’s make some examples (read more here)
    • Popping up an alert on the browser, it’s BOM functionality
    • Redirecting users to a web page by windows.location
    • Getting size of the screen by window.screen
    • Getting users user-agents by window.navigator.userAgent
    • Moving backward through history by window.history.back()

DOM

Let’s review Document Object Model (DOM):

  • The Document Object Model (DOM) is a programming interface for web (HTML and XML) documents
  • It represents the page so that programers can change the document structure, style, and content
  • Let’s make some example
    • Setting and reading Cookies for users by document.cookie
    • Accessing to the web page object by document.documentElement
    • Selecting a HTML element by document.getElementById
    • Redirecting users to a web page by document.location

Cookie

HTTP Cookies are small blocks of data created by a web server while a user is browsing a website and placed on the user's computer or other device by the user's web browser. When visiting a website, browsers automatically include Cookies belonged to the site (not always). Cookies have various attributes (Cookie’s flags), let’s take a look of each briefly:

  • domain → To specify the domain for which the cookie is sent
  • path → To specify the path for which this cookie is sent
  • secure → To set whether the Cookie is transmitted only over an encrypted connection
  • httpOnly → To set whether the cookie is exposed only through HTTP and HTTPS channels
  • expires → To set the cookie expiration date
  • SameSite → To prevent browsers from sending Cookies along with Cross-Site requests

Now let’s see what SameSite Cookie is. Rules:

  • None → The Cookies will be sent along with requests initiated by third-party websites
  • Lax → The cookie will be sent along with GET requests initiated by third-party websites
    • Only GET requests with top-level navigation will carry the Cookies - Top-level means that the URL in the address bar changes because of this navigation
    • Resources loaded with img, iframe, and script tags do not cause top-level navigation
  • Strict → The Cookies will not be sent along with requests initiated by third-party websites

But how to identify third-party websites? any websites which is not same site is third-party website. Site is extracted by the formula:

SOP

Please pay attention to the following scenario:

  • A company has a website, authenticated users can see their profile, if they are not logged-in, the login page is loaded
  • An employee logs in by their credentials (the Cookies are SameSite=None)
  • The employee visits memoryleaks.ir, there is a hidden iframe inside it sourced to company.com
  • Question: are the Cookies sent along the HTTP request?
  • Question: What’s the data loaded in the iFrame? an authentication page or the employee’s data?
  • The memoryleaks.ir has a code to read inside iframe’s content and steal the data, is it possible?

The Same Origin Policy stops reading inside iframe since the origin of the website (memoryleaks.ir) and iframe source (company.com) are not same.

  • Where does SOP come into the action?

!https://prod-files-secure.s3.us-west-2.amazonaws.com/afd876b5-b0b1-4394-ba11-16dae0b11001/5df00f05-e412-49ae-9191-9557525ce2b9/Untitled.png

How to bypass SOP ?

  • CORS
  • JSONP ( script tag )
  • postMessage → Sending and receiving messages between two different origins

CSP

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including XSS. There are two ways of enabling the CSP:

  • Response header → Content-Security-Policy: <policy-directive>
  • Meta tag →<meta http-equiv="Content-Security-Policy" content="<policy-directive>">

Where  <policy-directive> consists of: <directive> <value>, the list of directives can be found here. Let’s make an example:

Content-Security-Policy: **img-src** **<https://memoryleaks.ir>**; **script-src** **<https://www.google.com>**

This CSP policy only allows images sourced with https://memoryleaks.ir and Script tag sourced with https://www.google.com, let’s see CSP in action:

Recap

Let’s recap this session:

  • DOM and BOM provide features to work with web pages and browsers
  • DOM can be updated even after website is loaded completely
  • Cookies are data which is saved on users’ browsers (HTTP response headers + JavaScript)
  • Cookies have some attributes, httpOnly and SameSite are important concepts
  • Lax Cookies are sent by third-party websites only if a top-level navigation is done (GET requests only)
  • Origin is made by Scheme, Host and Port part of the URL, https://test.memoryleaks.ir/test, the origin is https://test.memoryleaks.ir
  • SameSite value is made by eTLD + 1, lib.memoryleaks.ir and test.memoryleaks.ir are SameSite but not Same Origin
  • We can send HTTP request on behalf of anybody who visits our website (may include Cookies). However, the response’s DOM is not accessible due to SOP
  • CSP is a response header which restricts clients in loading external resources

CORS

What is CORS

As we’ve learned in previous lesson, HTTP request can be issued on behalf of users browsing websites. However, some restrictions are applied by browsers:

  • Browsers only permit to send simple HTTP requests on behalf of users

  • Browsers send **Preflight HTTP request**if the request is not simple

    Simple HTTP Request

    • One of the requests methods:

      • GET, POST, HEAD

    • Some headers (Original headers cannot be changed, more info)

    • Only 3 content types:

      • application/x-www-form-urlencoded
      • multipart/form-data
      • text/plain

      Preflight HTTP Request

      If the cross origin HTTP request is not simple, an OPTION HTTP request will be sent which is called Preflight. If response headers permit the HTTP method and headers, the HTTP request will be sent. In addition to Access-Control-Allow-Origin and Access-Control-Allow-Credentials, preflight headers also include

      • Access-Control-Max-Age: <seconds> → value in seconds for how long the response can be cached
      • Access-Control-Allow-Methods → defines valid HTTP methods to access to resource
      • Access-Control-Allow-Headers → defines valid headers to be permitted to send

Impact of CORS misconfigurations

  • A CORS misconfiguration can leave the application at a high-risk of compromise
  • Impacts on the confidentiality and integrity of data
  • Allowing third-party sites to carry out privileged requests through your web site’s authenticated users
  • For instance, retrieving user setting information or saved payment card data

How to detect ?

Look for endpoints that return sensitive data.

How to prevent ?

Proper configuration of cross-origin requests

If a web resource contains sensitive information, the origin should be properly specified in the Access-Control-Allow-Origin header.

Only allow trusted sites

It may seem obvious but origins specified in the Access-Control-Allow-Origin header should only be sites that are trusted. In particular, dynamically reflecting origins from cross-origin requests without validation is readily exploitable and should be avoided.

Avoid whitelisting null

Avoid using the header Access-Control-Allow-Origin: null. Cross-origin resource calls from internal documents and sandboxed requests can specify the null origin. CORS headers should be properly defined in respect of trusted origins for private and public servers.

Avoid wildcards in internal networks

Avoid using wildcards in internal networks. Trusting network configuration alone to protect internal resources is not sufficient when internal browsers can access untrusted external domains.

Recap

  • There are some ways to exchange data between two different origins, PostMessage, JSONP, CORS, etc.
  • In order to update SOP, the server should set appropriate CORS headers
  • The browser fills the correct Origin header automatically, it cannot be forged
  • In terms of Cross-Origin HTTP request, if the HTTP request it not simple, browsers will send a Preflight request
  • If the request is not simply, browsers will follow up the Preflight’s response CORS rules
  • CORS misconfiguration happens when there is an endpoint which returns users sensitive information, and the site
    • Implemented CORS which accepts arbitrary Origin + ACAC
    • Implemented Cookies for authentication class
  • In many websites, there is a function which checks the Origin, it may not be safe against some vectors
  • If CORS accepts arbitrary Origin in a website, it’s not vulnerability unless the exploit works successfully

CSRF

What is CSRF ?

It’s called CSRF in Mitre, categorized as Broken Access Control in OWASP TOP10 2021. What is it?

  • It forces an end-user to execute unwanted actions on a web application in which they're currently authenticated
  • The action should be state-changing, such as update profile, change password, etc
  • How can attackers force a user to send HTTP request? it’s simple, we’ve learned it before
  • The authentication system should work with Cookies, if SameSite is enabled, an XSS is needed on any subdomain to exploit the flaw
  • Can any HTTP request be CSRFed? Can attackers forge any HTTP request? NO, it should be simple HTTP request
  • The SOP still exists, although the attacker doesn’t need the response (action has done)

Impact of CSRF ?

• It forces an end-user to execute unwanted actions on a web application in which they're currently authenticated

How to detect CSRF ?

Looking for and state-changing endpoints like update profile , password.

How to prevent CSRF ?

There are lots of protections to prevent CSRF. We should know all to bypass some bad implementations:

  • Using anti CSRF token to prevent forgery (most common)
  • Checking Referer header (the function which checks the Referer must be safe)
  • Using a custom header for each requests (or any action which makes the HTTP request complex)
  • Using lax cookies

Let’s review the anti CSRF token mechanism:

  • User sends HTTP request to change password form (GET request)
  • In the response, server returns an anti CSRF token bound to the user’s Session
  • User enters new password and submits the form (POST request), the CSRF token will be sent to server
  • Based on the Session, the CSRF token is checked in server side

Recap

  • CSRF forces an end-user to execute unwanted actions (Cookie + State changing)
  • The protection against CSRF is simple, adding a CSRF token or a custom header will prevent the attack

XSS

What is XSS ?

What is XSS? A vulnerability in which an attacker can inject malicious JavaScript code into a websites. The script will be executed on user’s browser. There are two types of XSS:

  • Normal XSS → occurs when HTML is being parsed by browsers
  • DOM XSS → occurs when JavaScript code is executed as a result of modifying the DOM

Each of types can be Reflected or Stored. In the reflected mode, no data is saved on the server, so the exploit should be delivered to user by a side channel. In the stored mode, the payload is saved in server and automatically injected to users when they visit vulnerable page.

There is also an XSS type named Blind XSS, the blind here refers that we cannot see the results of our payload. We inject payload and hope for a vulnerability. Other users (specially moderators) open the payload, we will be noticed.

Impact of XSS ?

  1. Session Hijacking 🔐
    • Attackers can use XSS to steal user session cookies, leading to session hijacking and unauthorized access to user accounts.
  2. Data Theft 📤
    • XSS can be exploited to steal sensitive information, such as login credentials, personal details, and financial data, entered by users on compromised websites.
  3. Malicious Actions on Behalf of Users 🔄
    • An attacker can perform malicious actions on behalf of the user, potentially leading to unauthorized transactions, changes to account settings, or other harmful activities.
  4. Defacement of Websites 🖼️
    • In certain cases, XSS may be used to deface websites by injecting malicious content or redirecting users to unwanted pages.
  5. Phishing Attacks 🎣
    • XSS can facilitate phishing attacks, where users are tricked into providing sensitive information by interacting with manipulated content.

How to detect XSS ?

Inject JS in inputs , path and read page HTML , JS source.

How to prevent ?

  • Input validation/sanitization

Recap

  • The XSS is to inject JavaScript code into a vulnerable website
    • XSS in rendering HTML page is called (normal) XSS
    • XSS in changing DOM is called DOM based XSS
  • XSS can be reflected or stored, in the reflected the exploit should be delivered to the victim
  • To discover XSS, we can use various tags and event handlers, such as img or svg
  • Websites use HTML encoding to prevent XSS, sometimes this protection can be bypassed
  • If a website is prone to XSS, we can perform any action that other users can do (SOP is gone)
  • Exploiting an XSS requires the intermediate knowledge of JavaScript and Browsers security

Open Redirect

What is Open Redirect ?

It’s called URL Redirection to Untrusted Site ('Open Redirect') in Mitre, not categorized in OWASP TOP 10 2021, it’s called Unvalidated Redirects and Forwards in OWASP cheatsheet. What is it?

  • Web application redirects user based on the untrusted input
  • Can be leveraged to achieve Cross-Site Scripting (XSS)
  • Can be leveraged to account takeover in some authentication flows
  • Can be leveraged to bypass SSRF domain whitelist to achieve full-blown Server-Side Request Forgery (SSRF)
  • It redirects an unsuspecting victim from a legitimate domain to an attacker's phishing site
  • Two types of Open Redirect can be occurred, header based or HTML/Javascript based

Impact of Open Redirect ?

  • Can be leveraged to achieve Cross-Site Scripting (XSS)
  • ATO in some case
  • Phishing site

How to detect ?

Looking for redirection or parameter like url

How to prevent ?

  • Input validation and sanitization

Server Side Request Forgery

What is SSRF ?

We force web server to send request from our behalf.

How to detect ?

Based on the situation, the SSRF can be full-blown or blind:

  • In normal mode, detection is based on the server response
  • In blind mode, detection is based on the other measures, such as time. Sometimes Out of Band technique helps us detect the flaw:

Recap

  • The SSRF is to make server send a crafted request to another server
  • In order to detect SSRF, out of band requests can be made (blind mod detection)
  • SSRF is like CORS, there is no vulnerability unless there is a success exploitation
  • Each SSRF scenario may be different, although there are some patterns: internal port scanning, leaking cloud metadata, etc.
  • IP based authentication has been flagged insecure after SSRF
  • Sometimes the default design of the website is to send HTTP request to other servers (example? profile picture), this is not a vulnerability
  • Redirect method is a common bypass to trick the checker function

IDOR

What is IDOR ?

Insecure direct object reference is a type of access control vulnerability in digital security. This can occur when a web application uses a user input for direct access to an object in an internal database but does not check for access control.

Impact of IDOR ?

  • Access to sensitive data

XXE

What is XXE ?

XML external entity injection (also known as XXE) is a web security vulnerability that allows an attacker to interfere with an application's processing of XML data. It often allows an attacker to view files on the application server filesystem, and to interact with any back-end or external systems that the application itself can access.

OR

If XXE parser interpret malicious input XXE happen.

Impact of XXE ?

In some situations, an attacker can escalate an XXE attack to compromise the underlying server or other back-end infrastructure, by leveraging the XXE vulnerability to perform server-side request forgery (SSRF) attacks.

How to detect XXE ?

  • Attack surface for XXE injection vulnerabilities is obvious in many cases, because the application's normal HTTP traffic includes requests that contain data in XML format.
  • Some applications allow users to upload files which are then processed server-side. Some common file formats use XML or contain XML subcomponents. Examples of XML-based formats are office document formats like DOCX and image formats like SVG.
  • XXE attacks via modified content type : Most POST requests use a default content type that is generated by HTML forms, such as application/x-www-form-urlencoded. Some web sites expect to receive requests in this format but will tolerate other content types, including XML.

How to prevent ?

  • Virtually all XXE vulnerabilities arise because the application's XML parsing library supports potentially dangerous XML features that the application does not need or intend to use. The easiest and most effective way to prevent XXE attacks is to disable those features.
  • Generally, it is sufficient to disable resolution of external entities and disable support for XInclude.

Recap

  • Web applications use different content types for data transmission
  • If the syntax of XML is correct, it’s called well formed
  • If DTD file validates XML successfully, it’s called valid XML
  • When a web application parses a malicious XML, it may result in XXE
  • Parameter entities are like general entities but they are declared by %
  • Parameter entities can only be used in a DTD, while general entities can only be used in the document content
  • Attackers use dangerous XML features to exploit XXE
  • There are six possible scenarios to read a file by XXE
    • Normal files + SYSTEM identifier
    • Special files + SYSTEM identifier + PHP wrapper
    • Special files + SYSTEM identifier + CDATA method
    • Normal files + OOB technique
    • Special files + PHP wrapper + OOB technique
    • Special files + CDATA method + OOB technique

Insecure Deserialization

What is Insecure Deserialization ?

It happens when an attacker loads untrusted code into a serialized object, then forwards it to the web application, if the web application deserializes the malicious input, it’s called insecure deserialization or object injection.

What is impact ?

  • The impact vary from information disclosure to RCE depends on programming language

How to prevent ?

  • Deserialization of user input should be avoided unless absolutely necessary.
  • If you do need to deserialize data from untrusted sources, incorporate robust measures to make sure that the data has not been tampered with

Recap

  • Web applications use serialization/deserialization for data transmission
  • Dangerous deserializing user-controllable data can result in object injection
  • To exploit insecure deserialization in the Python or NodeJs, there is no need to have source code
  • To exploit insecure deserialization in PHP, there is need to have source code (some cases not)
  • In PHP, the magic methods play key role in exploitation of object injection
  • In PHP, after an object is deserialized, the magic methods will be invoked automatically
  • In PHP, the source code should be reviewed to write an exploit code

Cache Attacks

What is Cache Poisoning ?

Web cache poisoning is an advanced technique whereby an attacker exploits the behavior of a web server and cache so that a harmful HTTP response is served to other users.

We're going to poison caches using unkeyed inputs like HTTP headers. This isn't the only way of poisoning caches - you can also use HTTP Response Splitting and Request Smuggling - but it is the most reliable.

What is Cache Deception ?

When CDNs, are tricked into storing and serving sensitive or private information intended for authenticated users to unauthenticated users.

How to detect ?

  • An HTTP header that explicitly tells you whether you got a cache or not

Impact of Cache attacks ?

  • Exposed users data
  • DOS attacks
  • XSS

How to prevent ?

  • If caching is necessary, restrict it to purely static responses to mitigate risks.
  • Assess which headers are supported by CDNs and disable unnecessary headers that could expose vulnerabilities.

Tools :

param miner

Questions

Knowledge Based Questions

To succeed as a penetration tester, you need foundational knowledge about cyber security. The interviewer will assess this by asking about well-known cyber security frameworks, practices, and terminology.

  1. What are the different penetration phases?
    • Reconnaissance, scanning, gaining access, maintaining access, and covering tracks.
  2. What are the different encryption types?
    • Symmetric and asymmetric encryption are the two main types. Using keys, symmetric encryption means users and information owners can use the same key to encrypt or decrypt information. Asymmetric means there's a private and public key to increase data protection for more sensitive information.
  3. What is an SSL/TSL connection?
    • An SSL/TLS (Secure Sockets Layer/Transport Layer Security) connection is a secure encrypted link between a client and a server over the internet. It ensures that data transmitted between them is encrypted and cannot be intercepted or tampered with by unauthorized parties.
  4. Differentiate between a vulnerability and an exploit?
    • A vulnerability is a weakness or flaw in a system. An exploit is a piece of software or code that takes advantage of a vulnerability to compromise a system.
  5. What is MIM?
  6. How do you scan a domain with NMAP if ICMP is closed?
    • I send sync packet to targeted port.
  7. How does WAF work?
  8. What is the difference between stateless and stateful?
  9. What is DNS rebinding ?
  10. We have IP/16 to scan , how to process it faster ?
  • Split IP
  • Do not complete the handshake ( Firewall maybe suspicious )

Technical Questions

  1. How many authentication models do we have?

    • OAuth
    • SSO
    • IP-based
    • Token
    • Cookie (session)

  2. How to bypass WAF?

    • When I send a request WAF intercepts it and if any malicious string exists in my request (based on WAF rules) the request will be dropped. So I have to set my malicious string in the packet that has an effect on the website and doesn't mismatch with WAF rules.

  3. Can we access JWT with XSS ?

  4. How to test APIs ?

  5. Could you describe XSS ?

  6. Could you explain CSRF?

  7. What is a SQL injection?

  8. Describe the process you would follow to assess and secure a web application from SQL injection vulnerabilities. Include the tools you would use, how you would identify potential vulnerabilities, and the steps you would take to mitigate them.

Personal Questions

An interviewer will typically start off by asking you personal questions. These questions are designed to ease you into the interview process and allow the interviewer to get a better sense of who you are as a person, what motivates and inspires you, and what type of personality you have.

  1. Tell about yourself. ( most important question )
  2. Describe the methodology you follow for a web application penetration test.
  3. What are the common vulnerabilities you might experience?
  4. What are some of your favorite penetration testing tools?
  5. Have you ever participated in Capture the Flag (CTF) or other online hacking games?
  6. Do you know any programming or scripting languages?
  7. How do you stay updated with the latest security threats and vulnerabilities, and how has this knowledge influenced your approach to penetration testing?

Behavioral Questions

To assess if you have the soft skills necessary to be a penetration tester, the interviewer will ask questions to understand how you will handle workplace situations based on past experiences. These questions allow you to showcase non-technical challenges you have previously overcome through your problem-solving abilities and soft skills.

  1. It's late, and as you are leaving to go home, your employer assigns you a task that must be completed immediately. What will you do? Accept the task, or refuse due to the late hour?
    • Considering how rarely this situation happens (maybe only once a year or once a month), I'll go ahead and accept the task.
  2. Describe a situation where you have worked with frustrating clients or colleagues in the past and how you have managed this?
    • Conflict resolution and adaptability are two soft skills required to flourish in any work environment. You may have to work with difficult clients or colleagues, and having the ability to handle these situations effectively is an important skill.
  3. Describe a situation where you had to explain a complex security issue to a non-technical stakeholder. How did you ensure they understood the risks and necessary actions?
  4. Tell me about a time when you discovered a significant security flaw. What steps did you take to address it, and what was the outcome?

Situational Questions

These questions put you in a hypothetical scenario, similar to ones you are likely to encounter when performing your role, and ask how you would handle such a situation. They assess your problem solving skills and ability to adapt to complex situations quickly.

  1. You get simple command injection on a web server through the address bar. What would you do to get a shell?
  2. You have discovered a web application that appears vulnerable to SQL injection, but you cannot use an automated tool to verify the vulnerability (e.g., sqlmap). How would you go about manually verifying the vulnerability?
  3. Can you describe a time when you discovered a significant security flaw during your bug bounty/research activities? How did you identify it, and what steps did you take to ensure it was resolved?
  4. Imagine you've discovered a critical vulnerability during a penetration test of a client's application. The client is resistant to making the necessary changes. How would you convince them of the importance of addressing the issue?

Resources

Questions and tips :

Technical Skill :

https://www.youtube.com/watch?v=Hs4W0kAuJLs( مصاحبه فنی امنیتی،قسمت اول)

https://www.youtube.com/watch?v=RWOk2FPPsx8( مصاحبه فنی امنیتی،قسمت دوم )

Soft Skill :

https://www.youtube.com/watch?v=NFSz67jXNT0 ( پنج نکته که در مصاحبه بدردمون می‌خوره )

https://www.youtube.com/watch?v=fmRZit4v9eg ( نکاتی برای موفقیت در جلسه مصاحبه استخدام )

https://www.youtube.com/watch?v=mJi7SSmDTVs ( تو مصاحبه شغلی، خودتو حرفه‌ای معرفی کن! )

https://www.youtube.com/watch?v=fmRZit4v9eg ( نکات مهم برای شرکت در جلسه مصاحبه کاری و استخدام )

https://www.youtube.com/watch?v=AczAAgfrBIA ( نکات مهم برای شرکت در جلسه مصاحبه کاری و استخدام )

https://www.youtube.com/watch?v=b_-HaLs0M2w ( پنج سوال حیاتی در جلسه مصاحبه که باید از کارفرما بپرسید )

https://www.youtube.com/watch?v=QisKakAfgCI ( آداب رفتن به مصاحبه کاری )