The flawed mindset of equating cybersecurity with Big

Recently I hosted a game event to empower the Women Who Code Boulder/Denver community with web security fundamentals. We played a game to think like an attacker and find vulnerabilities in one of the websites provided by the Security Innovation team. The players in the game had experience levels that varied from beginner to more than ten years in the tech industry. A few incredible players were crushing the vulnerabilities in the website, but the majority struggled to score points in finding vulnerabilities. After getting a few tips from the organizers, people started scoring points. The event made me realize that fewer people were coding with a security-first mindset, it is an afterthought and the consequences can be disastrous.

When building a portfolio website or a small application, do we need to worry about security? The news of compromised data is usually about big applications like banking, healthcare, and social networks. This makes us think attackers are not interested in small applications. For example, a restaurant menu webpage doesn't contain private or sensitive data. Attackers care about more than data alone. An attacker can access website servers and storage resources discreetly by compromising weak security protocols. If an attacker injects a code to get sensitive data, the customers who access the menu would be affected by the malicious code. So every application has some valuable resources or data.

What skills do we need to find the vulnerabilities of a website? This article is about some of the fundamentals of web security measures to implement in our applications. Awareness about common threats, and being able to recognize dangerous patterns help to address potential security issues.

SQL injection vulnerability occurs when an SQL query is coded with untrusted data. To identify this vulnerability, look for places where the application could be querying an SQL database. If a page isn't completely static, it's probably retrieving information from a database. Think about what SQL code the application might be running. For example, a login page URL can be

http://example.com/login?username=unameANDpassword=pwd

the SQL query might look like this:

SELECT * FROM Users WHERE Username='uname' AND password='pwd';

if an attacker can inject

http://example.com/login?username=admin'--'ANDpassword=pwd

then SQL ignores the query after '--' and will return the user details with username admin and let the attacker in. To avoid this, don't place user-provided input directly into SQL statements, properly escape characters that should be escaped.

Another security threat can be from the browser URL. URLs play a major role in the security decisions made by the browser. For example,

https://www.myexample.com/test?id=1#section1

URL indicates how to connect, where to connect, and what resource to retrieve. There’s also a part where parameters can be passed to the server. The final part can contain client-side parameters. If you change the parameters in the URL, ensure sensitive data is not returned by the server. In the above example, the server responds with data that has id=1. If you change the values of a form from the browser's developer tools and select submit form, the value should not be changed.

The data or text you provided is reflected back to the page. If that data isn't properly encoded, an XSS vulnerability might be present. For example, you try to log in as user "john" and the following error message is returned:"The user 'john' does not exist." Once you find a place where your input is being returned, try <plaintext> at that place; if not properly encoded, this causes the browser to display raw HTML.

There are a few more basic threats that can be avoided with proper awareness. OWASP provides more software tools and knowledge-based documentation on application security. Security first mindset is no longer a luxury but a must have in today’s environment. Too small to hack does not exist and cybersecurity must be table stakes for any web application.

Additional resources:

developer.mozilla.org/en-US/docs/Web/Security en.wikipedia.org/wiki/Certificate_authority