FCS BUG SUBMISSIONS
2022130
Group 24 Testing.
https://192.168.3.38/
Vulnerability 1:
MINOR RISKS: CSRF Risk: The csrftoken is sent via a GET request, weakening
CSRF protection since state-changing actions should use POST.
CSRF tokens should not be sent via GET because URLs can be logged, cached, or
leaked through browser history and referrers. GET is meant for safe, idempotent actions
and may be pre-fetched or cached, risking token exposure. Tokens in URLs are also
more vulnerable to interception, especially without HTTPS. Use POST or headers
instead.
ISSUES:Session Fixation: The sessionid is set pre-login and not regenerated
afterward, allowing attackers to hijack sessions
Info Leak: The messages cookie stores base64-encoded errors (e.g., "Incorrect OTP"),
exposing internal state even with no progress made in the website to reach anything
related to OTP verification.
Insecure Cookies: Missing Secure, HttpOnly, and SameSite flags on cookies increases
XSS/MITM risks
Vulnerability 2:
(Same core issues as admin login, just a different endpoint. Specially the incorrect OTP
message)
Vulnerability 3:
TYPE: CSRF Risk
The csrftoken is transmitted via a GET request to /register/, weakening CSRF
protection. State-changing actions like registration should strictly use POST
WHY IT'S A PROBLEM
CSRF tokens in GET requests are risky because URLs can be logged, cached, or leaked
via browser history, referrers, or proxies. GET is meant for safe, idempotent operations
and may be prefetched/cached, exposing tokens. Tokens in URLs are also more
susceptible to interception, especially without HTTPS enforcement
ISSUES
Session Fixation: The sessionid is issued pre-authentication and not regenerated
post-registration, enabling session hijacking if an attacker fixes a session before victim
login.
REMAINING SAME AS BEFORE 2.
VULNERABILITY 4:
URL : https://192.168.3.38/register/
Super ISSUE : Password and other data not hashed or encrypted.
TYPE: Plaintext Credential Exposure
The registration POST request transmits both email and password in clear text
([email protected]&password1=Tester1234), violating basic security
principles.Unencrypted credentials in transit can be intercepted via:
Proxy/server logs .
ISSUES
No Client-Side Hashing: Passwords should be hashed (e.g., bcrypt) before submission.
Weak Password Policy: Accepts simplistic passwords (Tester1234).
Session Fixation: Pre-auth sessionid persists post-registration.
Insecure Cookies: Still missing Secure/HttpOnly/SameSite flags.
Error Leakage: messages cookie reveals OTP failures prematurely.
VULNERABILITY 5:
This failure was a result of just simply trying to Register .
URL : https://192.168.3.38/register/
Testing for Server Ended since website can’t go forward.
GROUP 12 Testing:
https://192.168.2.244/
VULNERABILITY 20:
I intercepted the login request from the test website and was able to view
the username, password, and CSRF token in plain text. This means the
login form uses insecure transport or the HTTPS implementation can be
bypassed, likely due to a self-signed or unverified certificate. I could also
observe that the session ID gets set immediately after login, making it
vulnerable to session hijacking if intercepted. Since the CSRF token is
visible and not tied to a secure, rotating mechanism, I can potentially reuse
it for malicious requests. Overall, this site’s lack of proper HTTPS
enforcement and session protection exposes it to serious security risks.
VULNERABILITY 6:
URL : https://192.168.2.244/users/signup/
Password clearly visible in the POST method intercepted and such data if seen by man -
in the middle as in Burp Suite will cause security breaches to be super easy .
VULNERABILITY 7: [functional]
Too simple to be a proper website for interacting with many people , search bar doesn’t
display anything unless searched .
It was supposed to recommend people and products sans any input to force user
interaction but it isnt there.
Market place access blocked as well instead of being allowed to be in market place
sans verification .
Verification was meant to be if the user really wished to proceed to monetary tasks , but
viewing should be allowed but that too is missing.
No visible usage of pictures of user profile page or other people or products anywhere
VULNERABILITY 8:[functionality]
No visible functionality for video chat or calling as stated
in project.
GROUP 28 TESTING:
https://192.168.3.42/
Vulnerability 9:
URL : https://192.168.3.42/signup.html
Issue : Password is successfully hidden and encrypted but other details
regarding email and phone are still displayed as normal , doing so will
cause issues with acquiring contact data and people can relate the
person’s contacts to the websites and use their info sans permission
VULNERABILITY 10:
URL:https://192.168.3.42/mar
ketplace.html
Just writing <script>alert(“hackeddd”);</script> and adding to cart or
searching will cause this issue.
Steal Cookies – If the site’s cookies lack HttpOnly or Secure flags, attackers
can hijack sessions.
Hijack CSRF Tokens – Malicious JavaScript can steal anti-CSRF tokens,
enabling forged requests.
Force Malicious Downloads – Attackers can make users unknowingly
download harmful files .
GROUP 25 TESTING:
VULNERABILITY
11:[functional]
ISSUE: The website has not been deployed and in inaccessible.
GROUP 7 TESTING:
VULNERABILITY 12:
ISSUE: Text passwords and login info are available in both GET and
METHOD posts sans any encryption or hiding hence vulnerable to MITM
attacks.
VULNERABILITY
13:[functional]
ISSUE:Captcha bar input shown but no Captcha test available leading to
bad user experience.
VULNERABILITY 14:
ISSUE : Seach Bar function can be replicated and sent to victim via
messages and false links which leads to the user pressing the incorrect
Search button leading to a different site. As shown below
Left is fake site , Right is real . The fake one can be fed to victim via either
simple messages or by overlapping the fake modified search button on top
of the real button via acting / behaving as a legit advert.
VULNERABILITY 15:
PART 1: Viewability of Passwords, CAPTCHA, CSRF Token When credentials
and form data are sent in plaintext
● Username & Password – allows direct account access.
● CAPTCHA Answer – lets bots or attackers bypass human
verification.
● CSRF Token – lets the attacker forge valid requests on behalf of the
user.
● An attacker can log in as the user.
● CAPTCHA and CSRF protections are completely bypassed.
VULNERABILITY 16:
PART 2: Session ID Takeover
After login, the server usually gives a session token (cookie or header) to
keep the user logged in.
The attacker can reuse the session without logging and at the same
time as the actual user can create a double instance .
● No need for password or CAPTCHA anymore.
● They can fully impersonate the user — see profile, send messages,
even change settings.
● If it’s an admin session, attacker gets full control of the platform.
● This can lead to data leaks, privilege escalation, and permanent
account compromise.
VULNERABILITY 17:
ISSUE: MITM has access to both the session ID as well as the
CSRFMIDDLEWARETOKEN hence the MITM can access the same 2 step
verification page and see the QR code and go through with a 2 step
verification from their side and do malicious things via the victim’s own
login profile
VULNERABILITY 18:
I can see the user's personal message in plaintext, which means I'm
successfully eavesdropping.
I can view the CSRF token and session ID, letting me forge requests and
hijack the session.
This happened because the site isn't using proper HTTPS encryption or
secure cookie practices.
A secure site should:
● Enforce HTTPS and reject all HTTP traffic.
● Set cookies with Secure, HttpOnly, and SameSite=Strict flags.
● Rotate CSRF and session tokens after login or auth changes.
Because of these flaws, I can fully impersonate the user and read or send
private messages as seen here in “PERSONAL MESSAGE 1”
VULNERABILITY 19[Same pic
above]
I was able to MITM even though https:// was shown.
That means HTTPS wasn’t enforced properly, or the cert was invalid.
The site probably lacks HSTS, accepts weak certificates, or doesn’t
redirect all HTTP to HTTPS.
