</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.
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.
4. Make sure that all user inputs that will be generated to raw HTML are properly encoded.
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.
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
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
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
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