Really? Haha, No…


Over the weekend, I participated in GoogleCTF2017, my first Capture The Flag (CTF) event. It was both humbling and exciting.  

If you asked me three days ago what was the absolute worst thing someone could say to me, I would have given a completely different answer than today, but today, my answer is ‘Really? Haha, no…’ a phrase I heard way too many times as I worked through the challenges trying to find flags.

In a CTF, each team has a set of challenges that needs to be solved in order to find the flag and grab the points. The flag is usually a piece of code =>CTF{this-is-a-flag}<=.  

CTF competitions touch on many aspects of information security including cryptography, steganography, reverse engineering, forensics, and other topics.

There are three common types of CTFs 

  • Attack and Defend
    • Red Teams (Offense) vs. Blue teams (Defence) actively attacking and defending network infrastructures.
  • Jeopardy.
    • Challenges are broken up into multiple topics ranging from easy to difficult, to insane. 
  • Mixed.
    • Varied formats. Depends upon the host of the event.

GoogleCTF2017 was set up as a Jeopardy-style event, and it turns out that I knew more than I thought; Moreover, it was a wonderful experience competing against peers and picking up mad new skills while expanding upon my security knowledge.

In order to increase my skills in preparation for this CTF (and many others to follow), I used the websites below to practice and train.

As a Front-end developer, knowing how to exploit your own web applications before a cyber criminal can is critical and Google Gruyere is an invaluable resource. You ‘learn by doing’ and in that process, you come to understand how applications can be attacked using cross-site scripting vulnerabilities (XSS) and cross-site request forgeries (XSRF). Additionally, it allows the user(s) to find, fix, and avoid vulnerabilities and other bugs that have an impact on security including

  • Denial-of-service (DoS)
  • Information disclosure.
  • Remote code execution.

However, the greatest part of the weekend I have neglected to mention so far was the elation you feel when you use tactics and exploits to find a flag, and it works, i.e., ‘you have successfully hacked something, and you captured a flag.’ Today, I realized, I belong in this field.


995 points, six challenges, ten hours, two days.

  • 1 Miscellaneous
    • Start Here (FAQ)
  • 3  Crypto Challenges
    • Crypto Backdoor
    • Introspective CRC
    • Shake it
  • 1 Pwn
    • Inst Prof
  • 1 Web
    • Joe

You don’t have to be an expert in order to compete in a CTF. You just need an unrelenting curiosity and passion to never quit!  The purpose of the competition, besides capturing the flag,  is to recognize your strengths and more importantly your weaknesses. CTFs require a great deal of work and dedication but are highly rewarding. Strive for excellence.


Not so fast. Is that Web App secure?


I have been waiting for this call my entire life-The chance to host Uncle Murph’s birthday celebration. The best part was creating your own individualized version of his favorite cake from a recipe known only by my Aunt Kate and a few chosen family members.

With shopping list in hand, I was off to the market. Arriving back at home with the bounty of ingredients laid out before me measured and in order. However, something was awry, nothing but space where the most vital ingredient was supposed to be. Somehow, I overlooked it. Uncle Murph’s cake would not happen without a return trip to the market. Nevertheless, out of chaos comes opportunity because that day, the idea for a web app was formed.

My web application was not just your run of the mill shopping application, but a fail-safe meal (s) prep guide targeting anyone who returned from the market missing critical items. Applying Python with JavaScript for utility and function, a month of my time and 100+ lines of code later my Chef’s Fail-safe Prep App was complete. (Not so fast!)

A recommended security code review revealed that I would need at a minimum 500+ additional of lines of code to account for all the things that could and most likely would go wrong.

Wait, what? Stressed throughout my education in writing code was that the internet was built for ‘openness and speed,’ not for security. Security could always be added in at a later time. However, the development of my app imparted with me that writing good code is an enormous task. If not done correctly, a range of execution issues and errors can occur including two very well known web exploits; Cross-site request forgery (XSRF) and Cross-site scripting (XSS). Just what are these exploits?

  • XSRF attacks trick a user’s browser to send a forged HTTP request, including the user’s session cookie and the authentication information to a vulnerable web application. The XSRF allows an attacker to force the user’s browsers to generate requests allowing attackers to update account details, make purchases, logout, and login.” Wikipedia
  • XSS attacks occurs when malicious scripts are injected into trusted websites. The malicious script is passed to the end user’s browser. Once executed, the malicious scripts (JavaScript, VBScript, ActiveX, Flash, or HTML) can access any cookies, session tokens, or sensitive information retained by your browser and used with that site. XSS attacks allow for the attacker to gain a high level of control over the user’s system and communicate directly with the site that the user is connected.” Wikipedia

The fundamental difference between XSRF and XSS is inside the ‘victim’s browser.’ An XSRF goal is to exploit the trust that a website has in the visitor’s browser While the XSS is intended to exploit the trust the user has for a specific internet site.

For a deeper understanding of XSRF and XSS and other vulnerabilities can be found in the Open Web Application Security Project (OWASP) Top-10 list; which identifies the most critical application security risks. The top-10 is an industry best practice in preventing web app vulnerabilities and is utilized by many individuals and security organizations.OWASP

The amount of data managed by web apps is growing exponentially, driven by business demand. From online banking to your next Uber ride and everything in between. Web applications are entrusted to manage our most confidential and personal information securely; failing to grasp the nature of this trust can be hazardous. On balance, a single vulnerability can lead to data breaches; it can also result in the theft of Personally identifiable information (PII) which often proves the most costly and detrimental to organizations. Negative headlines, financial and reputational penalties, while legal and regulatory sanctions can quickly escalate into the millions of dollars.

Two worthy mentions of web app attacks include Yahoo! And  Ashley Madison.


  • Multiple data breaches in 2012, 2013, 2014
  • Estimated 1 Billion users affected.
  • Yahoo! Proprietary Source Code was appropriated.
  • PII compromised including:
    • Names
    • Telephone Numbers
    • Dates of Birth
    • Encrypted Passwords
    • Unencrypted security questions

Ashely Madison-

  • 11+ million passwords appropriated.
  • 30+ million private accounts compromised.
  • Identities exposed and targeted directly.
  • Organizations associated with Ashley Madison may face both financial and reputational damages.

In Verizon’s 2016 Data Breach Investigations Report (DBIR), the report identified, web application attacks accounted for a total of 5,334 total incidents, while 908 were responsible for confirmed data disclosure. Moreover, “95 percent of the confirmed web app breaches were financially motivated.”


Source: Verizon

When it comes to web app security, complacency is not an option. Unfortunately, Secure coding is often a postscript. Until of course, a security breach is exposed, and then it is too late.  Developers need to incorporate best practices into their development. Moreover, it is not satisfactory to find a few vulnerabilities during testing; you need to uncover them all. The risks are inestimable.

Below, find my ultimate shopping list helper written in Python Try it. Have fun! Learn!

shopping_list = []

def remove_item(idx):
index = idx -1
item = shopping_list.pop(index)
print(“Remove {}.”.format(item))

def show_help():
print(“\nSeperate each item with a comma.”)
print(“Type DONE to quit, SHOW to see the current list, and HELP to get this message.”)

def show_list():
count = 1
for item in shopping_list:
print(“{}: {}.”.format(count, item))
count += 1

print(“Give me a list of things to shop for.”)

while True:
new_stuff = input(“> “)

if new_stuff == “DONE”:
print(“\nHere is your list:”)
elif new_stuff == “HELP”:
elif new_stuff == “SHOW”:
elif new_stuff == “REMOVE”:
idx = input(“Which item? Tell me the number. “)
new_list = new_stuff.split(“,”)
index = input(“Add this at a certian spot? Press enter for the end of the list. ”
” or give me a number. Currently {} items in the list.”.format(
if index:
spot = int(index) -1
for item in new_list:
shopping_list.insert(spot, item.strip())
for item in new_list:
Cybersecurity is a shared responsibility. Stop. Think. Connect.