Cross Codes Blog





Blog home





</script> is dangerous

29 April 2019 | Engineering

One of my coworkers, also a backend developer, asked for my assistance in addressing a UI bug resulting from cross-site scripting. The first thing to address was the fact that there was no guard against cross-site scripting for the text field. This resulted into an HTML parse error whenever a user inputs "</script>" and returns. The first thing I wanted to do was address the error that seems to be XSS related before moving on to what was planned as a UI bug fix task. However, the UI bug turned out to be the direct result of the parse error. JSON data would be displayed in the interface from a user input of "</script>". What was happening was user-inputted data would be generated into raw HTML via the call @Html.Raw(Newtonsoft.Json.JsonConvert.SerializeObject(Model)). An unintended consequence would result from the text "</script>" getting generated as raw HTML where the browser would interpret the text as a terminating script tag. As a result, the browser would interpret everything after the generated script tag as literal elements due to the parse error. Right after the script tag within the area where raw HTML gets generated, there is generated JSON data intended to be parsed but is output instead.

TAKEAWAYS
1. Make guarding against known security vulnerabilities the first task to complete.
2. Address any bugs found occurring before the originally planned bug to fix. That might be the source of the problem to begin with.
3. Be aware of the possibility of HTML/ JavaScript syntactically correct text a user can input.
4. Make sure that all user inputs that will be generated to raw HTML are properly encoded.





Mob programming

28 April 2019 | Industry

I was in a meeting about a development practice known as "mob programming", a concept proposed to be incorporated in my company's development process. The main idea is to have a group of typically 4 - 5 developers (sweet spot) each alternating between who will be behind the computer actively writing code while the rest of the developers in the group are watching and communicating suggestions. The one coding is referred to as the driver while those behind the driver are referred to as the navigators. The navigators are all responsible for guiding the driver. This method of software development requires everyone's watches to be strictly in sync (ie. no coding after 5pm). This addresses the problems of bugs resulting from late check ins. Typically the driver gets 15 minutes behind the keyboard to actively code. Due to this limited amount of time, coming up with ideas is the responsibility of the navigators, not the driver. This time synchronized and divided responsibility of labor is meant to maximize efficiency. In order to accomplish this, psychological safety would need to be emphasized as a significant factor in successful development.

Pros
Cons
Developers are strictly time synchronized Active coder isn't fully engaged mentally
Work is divided and shared Preemptive programming on one project at a time
Higher throughput Higher latency





File upload fiasco

20 April 2019 | Engineering

At work, I was tasked with adding security enhancements to the resume upload feature on ASHCompanies. Part of the additional features I was asked to implement involved verifying that the file signature matched with the file extension on the filename of the uploaded resume. To accomplish this, the first idea that came to my mind was using a stream object to read the bytes of the file, save the read contents to a variable, then use that variable for validation. Reading the file contents was where the fiasco began. It turned out that reading the file contents through a stream was actually removing the specific bytes read thus corrupting the uploaded resumes. QA only tested the security features assuming that the uploaded resumes would be unchanged. Once deployed to production, it only took 24 hours for HR to notice this issue.

Looking into the code, I noticed the files being uploaded via HTTPPostedFileBase. This is a .NET class used to upload files to a server by transferring the bytes through the HTTP protocol. I verified that the specific bytes I'm reading to verify the file signature (only the first 4 bytes) were the only bytes being erased from the uploaded file. The fix was to reset the file stream position. This is typically not required for regular file stream objects but I'm guessing this is different for the HTTPPostedFileBase class. Since the file bytes are being transferred over a network, having a stream read over specific bytes seems to cause failure of said bytes to be successfully uploaded unless the stream position is explicitly set back to the position of which bytes are expected to make it through the upload. We want all of the bytes so this meant setting the file stream position to 0.

HTTPPostedFileBase contains an InputStream object. The fix is done by the explicit initialization HTTPPostedFileBase_reference.InputStream.Position = 0; after reading. Also, it is important to avoid the HTTPPostedFileBase_reference.InputStream.Close() call before setting the position to 0.





Are comments necessary?

18 April 2019 | Experience

At work, I ran into a code block that looked like the following:
if some_condition do
   something()
   // something_else()
else do
   // something()
   something_else()

I thought this looked peculiar so I mentioned it on Slack. One of my coworkers gladly addressed my confusion. The reason for this code style is related to debugging. The if statement was checking whether the application is running locally, or on a network able to send email. If it ran locally, it would generate a text file of the email that would normally be sent and save it to a folder. The idea is to comment out the correct function call depending on whether the application is running locally or on a network. As a college student, I was overtaught my commenting habbits. It seems trivial and ideal to write in a high level exactly what the code is doing. However, this can become micromanagement at times; having to write file/ function headers and inline comments. It seems subjective around software development teams however, commenting too much is possible and never optimal. I asked my coworker if it would be ideal to comment the purpose of this code block to prevent confusion when someone else works on it in the future. He advised against it for a couple reasons. First off, development is constantly changing the code's structure possibly rendering any comments related to the current scenario to eventually be outdated. Second, the functions are named after exactly what they do. This eliminates the need for function headers above functions, and inline comments where the functions are called. Overall, even though commenting one's code is important, it's not always the answer. This is an example of where it's not but instead, it's overkill. It is possible to reduce the amount of labor and still maintain code cleanliness by following best practices when naming functions. This removes excess need to comment, especially in cases such as this where the effort and possible lack of future relevance in commenting outweighs the need to document a code block.





New job new plan

6 Februrary 2019 | Experience

I am proud to say that all my efforts in learning new technologies, keeping up-to-date, networking, interviewing, and maintaining my website have finally accomplished its purpose in landing me my first role as a fulltime software engineer. With that being said, this significant milestone in my career has rendered it unclear about how I will maintain this blog. For sure I will be on hiatus in regards to my postings given the work load I will be expected to handle and I'm not sure when I will post again. However, I will give the best of my efforts to come back as I continue to grow from where I currently am in my professional journey. I am very much interested in continuing to document my experience. Given where I am going in my career, here are my current plans/ goals:

1. Website redesign and redevelopment - looking to change the look of my website, apply more web development principles and best practices I am expected to learn from my current job, gain knowledge on more web development technologies in addition to what I already know, possibly change my domain name
2. Work on an embedded networked system - continue to do projects outside of work focusing on my interests and skill set I wish to acquire
3. Gain knowledge on cybersecurity - continue learning about cybersecurity and possibly apply it to a personal project
4. Continue learning about various topics in software engineering - agreed to meet with colleagues weekly to learn various professional skills and gain insight for what the future holds for our careers, learn from each other
5. Get back into music - my technical development has robbed me of my former time as a musician, looking to develop vst plugins, write music, and get into piano recitals




<< < 1 2 3 4 > >>



© Copyright 2018 Jeremy Cruz