I am documenting every day of my cybersecurity learning journey publicly. This is Day 5. Previous posts are on my profile.
What was covered today
DNS record types in depth, TryHackMe HTTP in Detail and DNS in Detail rooms, Python chapters 1 and 2 from Automate the Boring Stuff, and writing and running my first Python script in Kali Linux.
The thing about cookies I almost missed
I was working through the TryHackMe HTTP in Detail room and hit the section about cookies. I already understood roughly what cookies were — they store your login session, so you do not have to log in on every page.
What I did not understand was the security flags. Specifically HttpOnly.
Here is what HttpOnly does: when a cookie has the HttpOnly flag set, JavaScript cannot read it. That sounds like a minor technical detail. It is not.
If a website has a cross-site scripting (XSS) vulnerability — meaning an attacker can inject JavaScript into a page — and your session cookie does not have HttpOnly set, that injected script can read your session cookie and send it to the attacker. The attacker now has your session. They are logged in as you. They never needed your password.
The fix is one word. HttpOnly. The developer adds it when they create the cookie. Done. Session cookie theft via XSS becomes impossible.
But it is missed constantly. Bug bounty hunters find this all the time on real production websites. It is in the OWASP Top 10 under broken authentication. Companies pay bounties for it.
I almost read past it because it looked like a minor detail. It is not minor. It is the kind of thing that separates a developer who understands security from one who does not — and it is exactly what a SOC analyst needs to recognize in an incident report.
DNS record types — why each one matters
I covered basic DNS on Day 3 — what DNS does and how to query it. Today was about the specific record types and their individual security implications.
The ones that surprised me most:
TXT records reveal a company's entire email security posture. SPF, DKIM, and DMARC records are all stored as TXT records. If you query a company's TXT records and find no SPF record, you know their domain can be used to send spoofed emails that may pass spam filters. That is the foundation of business email compromise attacks.
CNAME records create subdomain takeover vulnerabilities. If a company has a CNAME pointing to a third-party service they no longer use, an attacker can claim that service and control what visitors to that subdomain see. There are documented cases of this affecting major companies — subdomains of Microsoft, Google, and hundreds of others have been vulnerable to this at various points.
PTR records are used in forensics. When you see a suspicious IP in a log file and do a reverse DNS lookup, the PTR record tells you what domain it belongs to. This is one of the first things an analyst does during incident response when investigating an unknown connection.
Starting Python
I have been looking forward to this and slightly dreading it at the same time. I have never written code before.
Two chapters in — the dread is mostly gone.
Python reads like instructions written in near-English. Al Sweigart writes Automate the Boring Stuff like he is explaining things to a friend, not writing documentation. Chapter 1 covers variables, data types, and basic operators. Chapter 2 covers flow control — if statements, for loops, and while loops.
What clicked for me:
Every security tool at its core is just a loop. A port scanner loops through port numbers and checks each one. A password cracker loops through a wordlist. A directory brute-forcer loops through paths. Chapter 2 — specifically the for loop and range() function — is the conceptual foundation for all of those tools.
for port in range(1, 1025):
# check if this port is open
# This is the core of a port scanner
That is not a working port scanner yet. But that mental model — loop through a range of numbers and do something with each one — is the entire concept. The next few days will add the socket library and the actual connection logic. But the loop is the skeleton.
First script written and run
Here is what I wrote today:
name = input("What is your name? ")
print("Welcome to cybersecurity training, " + name + "!")
print("")
for i in range(1, 6):
print("Loading security module " + str(i) + "...")
print("")
print("All modules loaded. Training begins now.")
I ran it with python3 first_script.py in my Kali terminal. It worked on the first try. That felt good.
More importantly, when I made a mistake earlier and forgot a closing parenthesis, Python gave me this:
SyntaxError: '(' was never closed
Exact line. Exact problem. I fixed it in ten seconds. Error messages in Python are genuinely helpful, which is not something I expected going in.
What five days of this have felt like
Looking back at the week:
Day 1: OSI model — networking theory
Day 2: Wireshark — watching packets live
Day 3: Nmap — scanning real servers
Day 4: Linux and Bandit — working on a remote server
Day 5: DNS records, HTTP internals, Python starts
Every day has had at least one moment where something clicked through doing rather than reading. Today it was the cookie flags — reading about them was fine, but working through the TryHackMe room where you actually exploit the absence of HttpOnly made it concrete.
Tomorrow: more Bandit levels, Python functions and lists, and writing a port scanner. That is the goal for Day 6 — first real security tool.
Notes are on my GitHub — link on my profile.
https://github.com/narasimhamallegari/cybersecurity-notes
Top comments (0)