If 'X-Frame-Options' not in response header, the X-Frame-Options header tells the browser
whether a page can be embedded in an iframe.
Without this header, attackers can embed the vulnerable website in an iframe and perform
clickjacking attacks where an attacker tricks a user into clicking on a malicious element.
To prevent clickjacking attack:
DENY: Most secure option, completely prevents the page from being embedded in an iframe on
any other website.
SAMEORIGIN: Allows the page to be embedded in an iframe only on the same domain.
ALLOW-FROM uri: Allows the page to be embedded in an iframe only on the specified
domain provided in the "uri" value.
if 'X-Content-Type-Options' not in response header, the X-Content-Type-Options header
prevents browsers from interpreting files as a different MIME type than declared by the server. It
has one valid value:
nosniff: Instructs the browser to follow the declared Content-Type of resources and not to
"sniff" or guess the type.
The Content-Type header is a bit like the address on an envelope. To send the data to the right
place internally, the browser first needs to read the header value to determine what kind of data it
is dealing with. If it says image/png, the browser will try to process a PNG file. If it’s
application/xml, it will try to display an XML file.
Without the X-Content-Type-Options: nosniff header, browsers might guess the MIME type of a
file based on its content, potentially leading to MIME-type confusion or cross-site scripting
(XSS) vulnerabilities.
Many web servers, particularly older Apache, Nginx, or IIS versions, do not include this header
by default unless explicitly configured.
Directory Indexing Found (http://192.168.1.125:80/includes/):
Directory indexing means that the server is configured to display the contents of a directory if
no index file (e.g., index.html or index.php) exists or if the server explicitly allows directory
listing.
Directory indexing allows attackers to enumerate files and subdirectories.
Attackers can discover sensitive files (e.g., configuration files, backup files, scripts) that are not
meant to be publicly accessible.
This can provide critical information about the web application structure, file naming
conventions, and technologies in use.
Discovery of sensitive files like config.php, .env, or .htaccess containing database credentials,
API keys, or server configurations. Gaining insight into the application’s internal structure,
which helps in planning further attacks.
The includes directory is typically used to store:
1. Shared scripts or functions.
2. Header and footer files.
3. Utility scripts like database connectors or authentication logic.
Files like footer.php and header.php often contain reusable code for web pages. They may
include:
Static Content: Layout elements like HTML headers, footers, or navigation bars.
Dynamic Content: Calls to APIs, database queries, or authentication checks.
These files may reveal internal URLs, API endpoints, or authentication mechanisms used by the
web application.
For example, header.php could contain tracking scripts that expose the internal database system
or external integrations.
Manual testing trying with wget, curl command to download the discovered files. Then, open
with visual studio code.
If the web application does not include the HttpOnly attribute, which is a critical security
measure for protecting sensitive session data.
The HttpOnly flag is a security feature that can be applied to cookies. When set, it prevents
client-side scripts from accessing the cookie. This reduces the risk of Cross-Site Scripting (XSS)
attacks.
composer.json:
This file is used in PHP projects managed by Composer, a dependency management tool.
It contains metadata about the project, including:
Dependencies the project uses.
Version constraints for packages.
Scripts or commands triggered during deployment.
If exposed, it could be:
Reveals all dependencies the project uses.
Attackers can identify:
Outdated or vulnerable versions of dependencies.
Potential attack surfaces from known vulnerabilities (CVEs) in the listed packages.
composer.lock:
This file locks the dependencies versions being used by the application.
It ensures consistency across different environments during deployment.
If exposed, it could be:
Provides exact versions of the dependencies.
Enables attackers to:
Confirm specific vulnerabilities by checking package
Exploit dependencies known to have security flaws.
