As a Cyber Engineer, I face many unique challenges on the job. At my job, I work both sides of cybersecurity, offense and defense, on web applications. In general, my job consists of internal penetration testing of web applications and engineering subsequent security patches for any vulnerabilities I find while pentesting. To give you an insight into what a typically day might look like for a cyber engineer, I have chronicled a day on the job.

Before I can fix a security vulnerability, I must find it. Today I will be searching for cross-site scripting, XSS, vulnerabilities. XSS vulnerabilities are present many web applications and security for these vulnerabilities are a perpetual issue for web developers and cyber engineers alike; hence why it is a mainstay on the OWASP Top 10. An XSS vulnerability steams from the mishandling of user input and allows a malicious user to execute JavaScript code on another user’s browser. To find these issues I use a web browser (Firefox or bust!) and BURP suite HTTP proxy, which allows me to use the web app from a browser like normal, but also edit my HTTP requests before sending them to the web app. Most of my security testing occurs on a local version of the web app in question; this allows me to freely test the app without the chance of crashing the system for anyone else. With my local web server running, I login and begin testing various user inputs to identify what data is being stored on the server’s database and later displayed back to the user; these types of inputs are typically where XSS issues are found. After identifying a few inputs that are stored in the database and later displayed in a table to the user, I start focusing my security testing efforts on these inputs. Inputting a few XSS payloads quickly reveal that one of the inputs is displayed back to the user without being sanitized, allowing me to execute JavaScript code from the web page. To ensure I understand the full breadth of this issue, I thoroughly search similar areas of the web app to see if my XSS payload input is displayed and executed on other parts of the site. Next, I create a record of where and how I identified the security issue, including screenshots and example payloads that prove the vulnerability.

After I have discovered, tested, and recorded a vulnerability, I began patching the vulnerable code. My first step is to find out what server-side file handles the vulnerable input. To do this, I typically will put some breakpoints around where I think the input is processed and run the site on a local web server in debug mode. After stepping through the process and identifying where the input is handled, I start implementing the necessary input sanitation libraries. To fix today’s issue, I will use an XSS sanitation library that takes a raw input string and returns a sanitized string with any dangerous characters HTML encoded. To properly implement this patch, I rewrite the input handling portion of the code to first send the user’s input to the XSS sanitation function, which will make the string safe to display on the page, and then to rest of the code that displays the input on the page. After completing the patch, I send my code to a colleague for peer evaluation, where they will check that my code did not affect the site’s functionality and that the patch works for them. Finally, the patch reaches a test environment where I verify that the security issue is fixed and that my code is ready to ship to the customer.

In summary, today we found an XSS vulnerability using a web browser and BURP and then triaged the security issue from initial discovery to finalized security patch. I greatly enjoy the diversity cyber engineering can provide in a single day. Although, we have walked through a typical day on the job, no two days are alike; tomorrow I might face a completely different challenge and need to engineer a new solution. Hopefully this blog has given you some insight into what it is like to be a cyber engineer and how you might handle a vulnerability from discovery to security patch.

gond0r