1 Prevent Cross-Site Scripting (XSS):

● Create
. a web page with a form where user input is displayed.
● Show how unescaped user input can lead to XSS. Implement
● input validation and escaping to prevent XSS attacks.

2. Cross-Site Request Forgery (CSRF)

Protection:
● Implement a CSRF token in a form submission to prevent unauthorized
requests.
3. SQL Injection (SQLi) Prevention:

● Create a search form connected to a database. Implement prepared

● statements to prevent SQL injection vulnerabilities.
I made This HTML Webpage that takes the input from the user. This Web
page is vulnerable to XSS , let’s see the method :

We’ll use a site with a search box that refreshes the page with your search query in the
URL and displays the results at the bottom. Here’s a sample site to explore :

Alright, let’s dive into trying a Cross-Site Scripting (XSS) attack on a site with a search
box. Here’s how I went about it:

1. Starting Simple: My first attempt was to insert JavaScript directly. So, I

typed
`<script>alert('hi')</script>` into the search box and hit search. But nothing happened—
no
alert box popped up. This is because script tags injected after a page load typically don’t
execute.
2. Trying a Workaround: To get JavaScript to run, I needed a new approach. Instead of
using a `<script>` tag, I used an image tag with an `onerror` event. Here’s what I tried:
`<img src onerror="alert('hacked')"/>`. I entered that into the search box and hit
submit.
 3. Success!:Thistime,analertboxpoppedupwithmymessage.The`onerror`event
triggered as the browser tried to load an empty image source, running the JavaScript
I’d written. Even

better, the search query stayed in the URL. If I sent that URL to someone else, they’d
see the alert too.

4. Potential Malicious Use: This kind of XSS can be used for more than just alert
boxes. For example, I could write code to steal a user’s session cookies, sending them
to my server and allowing me to log in as that user.

This method of injecting JavaScript shows how a site vulnerable to XSS could be
exploited.
In my implementation of a login form, it's crucial to be aware of potential
vulnerabilities, especially Cross-Site Request Forgery (CSRF). Invicti highlighted a
possible CSRF attack in login forms, which can have significant implications for user
security.
Understanding CSRF in the Context of My Login
Form
In a CSRF attack on a login form, an attacker can forge a login request using their
credentials. If successful, the victim's browser would receive a Set-Cookie header from
the honest site,

effectively logging the attacker into the victim's account without their knowledge. This
can lead to unauthorized access to sensitive information, as the attacker can exploit the
session cookie that binds subsequent requests to the victim's authenticated session.

For example, if my login form does not implement proper CSRF protections, an
attacker could send a malicious link containing an HTML form like this:
<form method="POST" action="http://honest.site/login">

<input type="text" name="user" value="h4ck3r" />

<input type="password" name="pass" value="passw0rd" />

</form

>
 <script
>
document.forms[0].sub
mit(); </script>

When the victim clicks this link, the form is automatically submitted, and they could
be logged in as the attacker, exposing them to various threats.

Impact of CSRF Vulnerability on My Login Form

The impact of CSRF on my login form, however, is somewhat mitigated. Although an
attacker can exploit XSS vulnerabilities to capture login credentials, the lack of an active
session limits the attacker's capabilities. In my scenario, while the CSRF vulnerability exists,
it can lead to the

attacker forcing the victim to log in and potentially triggering an XSS exploit. If my login
form is vulnerable, the attacker might present the victim with a familiar login interface that
captures their username and password.
 Addressing CSRF in My Implementation

To counteract these risks in my login form, I will implement CSRF tokens. Each time the
form is loaded, a unique CSRF token will be generated and embedded in the hidden input
field. This token will be checked upon form submission to ensure that the request is
legitimate. If the token is missing or does not match the expected value, the server will
reject the request.

<input type="hidden" name="csrf_token" value="<?php echo $_SESSION['csrf_token']; ?

>">

Additional Security Measures

In addition to CSRF tokens, I can consider employing custom HTTP headers when
making AJAX requests. Since browsers prevent sites from sending custom headers to
another
domain, I can use this feature to reinforce the security of my application. By using
XMLHttpRequest or jQuery's AJAX methods, I can include validation tokens that
further
confirm the legitimacy of
the request.
For example, using jQuery, I could set up custom headers for all requests like

this:

$.ajaxSetup(

{ headers: { 'x-my-custom-header': 'some value' }

})

So , by implementing CSRF protection through tokens and being aware of the

potential vulnerabilities associated with my login form, I can significantly reduce the
risk of unauthorized access. Understanding the implications of CSRF attacks helps
me create a more secure web application, ensuring that user data and credentials
remain protected against malicious actors.
 1. VulnerabilityScanning:
● Use OWASP ZAP or Burp Suite to test for vulnerabilities such as XSS,
CSRF, and SQL Injection.

● Document any vulnerabilities found and describe how they were

fixed.

2. Report
● Include screenshots of your test results. Write a summary of the identified
Findings:
● issues (if any) and how they were resolved.

Now , Let’s Perform Using Browser Developer Tools to inspect headers and network
communication.
I wanted to ensure that no insecure HTTP requests were being sent from my browser, as
these can be vulnerable to Man-in-the-Middle (MiM) attacks. To do this, I used the
Browser Developer Tools to inspect the headers and monitor network communication. By
examining each request, I could see whether the connection was secured with HTTPS.
This allowed me to verify that sensitive information wasn't being transmitted over
unsecured channels, helping me maintain a higher level of security in my online
interactions.

IDENTIFIED ISSUE WITH MY WEBSITE

During the evaluation of my website's HTTPS configuration using SSL Labs, I identified
several issues contributing to its B grade, including vulnerabilities related to outdated
protocols, weak cipher suites, missing HTTP Strict Transport Security (HSTS), and minor
certificate chain issues. The vulnerabilities were as follows:

1. OutdatedProtocols:SSL3.0andTLS1.0werestillenabled.
2. WeakCipherSuites:Someweakciphersuiteswereavailableforuse.
3. MissingHSTS:HSTSwasnotenabled,exposingthesitetodowngradeattacks.
4. CertificateChainIssues:Minorissueswiththecertificatechainneededresolution.

To address these vulnerabilities, I disabled SSL 3.0 and TLS 1.0 to ensure only secure
versions like TLS 1.2 and TLS 1.3 are supported, updated the server to use only strong
cipher suites, and implemented HSTS by adding the appropriate headers. After
applying these changes, I re-evaluated my website and achieved a higher grade, which
significantly enhanced its security posture and deepened my understanding of the
importance of maintaining robust web security measures.
 CONCLUSION

In this lab, I successfully implemented and demonstrated core web security principles by building a secure web
application. Key achievements include:

1. Authentication&Authorization:

○ Implementedaloginsystemwithpasswordhashingforsecurestorage.
○ Establishedrole-basedaccesscontrol(Admin/User)usingcookiesorJWTfor
secure session management.

2. SecureSessionManagement:
○ EnabledHTTP-only,securecookiestoprotectsessiondata.
○ Configuredsessiontimeoutsandlogoutfunctionalitytoensuresessionsecurity.

3. HTTPSCommunication:
○ SetupSSL/TLScertificatesusingLet’sEncrypt/ZeroSSLtoenforceHTTPS
and secure data transmission.
○ ImplementedHSTStoenforcesecureconnectionsandconfiguredsecurity
headers to mitigate web-based attacks.

4. VulnerabilityMitigation:
○ AddressedXSSvulnerabilitiesthroughinputvalidationandescaping.
○ ImplementedCSRFtokenstoprotectformsagainstCSRFattacks.
○ AddedX-Frame-OptionstopreventClickjacking.

5. Testing&Reporting:
○ UsedtoolslikeOWASPZAPandBrowserDeveloperToolstoidentify
vulnerabilities such as outdated protocols, weak cipher suites, and missing
headers.
○ Mitigatedidentifiedissues(e.g.,disabledoutdatedprotocols,enforcedstrong
cipher suites, and enabled HSTS), improving the website’s security grade.

Key Outcome:
This lab provided a hands-on understanding of securing web applications against common threats and
vulnerabilities while implementing best practices for authentication, session management, and HTTPS
enforcement. This experience strengthened my skills in building secure systems, ensuring better protection of user
data, and mitigating real-world web security risks.