OWASP:
OWASP stands for Open Worldwide Application Security Project. It’s a non-profit group that
shares free resources about how to secure web applications and systems. The OWASP Top 10 is
a list of the 10 most common and dangerous security risks for web apps, many of which are also
important in network security.
OWASP Top 10 Vulnerabilities (2021 Edition – most recent)
1. Broken Access Control
What is it? Users can access things they shouldn’t (e.g., normal users accessing admin
pages).
Network risk: Hackers can move around inside the system and steal data.
2. Cryptographic Failures (Previously called “Sensitive Data Exposure”)
What is it? Weak or no encryption (e.g., sending passwords in plain text).
Network risk: Attackers can see or steal data during transmission.
3. Injection
What is it? Hacker inputs harmful commands into systems (e.g., SQL injection).
Network risk: Can give access to databases or entire systems.
4. Insecure Design
What is it? The system is not built with security in mind from the beginning.
Network risk: Even without bugs, attackers can find ways in.
5. Security Misconfiguration
What is it? Using default passwords, leaving ports open, or not updating systems.
Network risk: Attackers can easily enter and move through the network.
6. Vulnerable and Outdated Components
What is it? Using old software with known bugs.
Network risk: Hackers exploit these known weaknesses to get in.
7. Identification and Authentication Failures
What is it? Weak login systems (e.g., no two-factor authentication, easy passwords).
Network risk: Hackers can pretend to be users or admins.
8. Software and Data Integrity Failures
What is it? Trusting software updates or files that might have been tampered with.
Network risk: Hackers can inject malware or backdoors.
9. Security Logging and Monitoring Failures
What is it? Not tracking what happens in the system or ignoring alerts.
Network risk: Attacks go unnoticed for a long time.
10. Server-Side Request Forgery (SSRF)
What is it? Hacker tricks the server into making a request to another system (even inside
the network).
Network risk: Can lead to internal data exposure or scanning of other internal systems.
Why Is This Important?
These vulnerabilities are commonly targeted by attackers.
Fixing them helps keep:
Your network secure
Your data safe
Your systems protected
1. SQL Injection (SQLi)
SQL Injection happens when a hacker puts malicious SQL commands into a website’s input
fields (like search bars or login forms) to trick the database into doing something it shouldn’t.
What can happen?
Hackers can read, change, or delete data from the database.
They might even log in as admin without a password.
Simple Example:
Imagine this login form:
SELECT * FROM users WHERE username='admin' AND password='123';
Now, a hacker types this into the username field:
admin' --
The new query becomes:
SELECT * FROM users WHERE username='admin' -- ' AND password='123';
The -- makes the rest a comment, so it skips the password check!
How to prevent:
Use prepared statements (parameterized queries)
Validate user input
Don’t show detailed error messages to users
2. Cross-Site Scripting (XSS)
XSS happens when a hacker puts malicious JavaScript code into a website that other users see.
That code then runs in the victim’s browser.
What can happen?
Stealing cookies or session tokens (can hijack accounts)
Redirecting users to fake websites
Showing fake messages or popups
Simple Example:
A comment box allows users to type messages, but it doesn’t check for code. A hacker types:
<script>alert('Hacked!');</script>
Now every visitor to the page sees a popup!
How to prevent:
Escape special characters (<, >, ", ')
Use a Content Security Policy (CSP)
Sanitize user input before showing it on the page
3. Cross-Site Request Forgery (CSRF)
CSRF tricks a logged-in user’s browser into sending unwanted requests to a website without
their permission.
What can happen?
Making a user transfer money
Changing account settings
Deleting data – all without the user knowing
Simple Example:
You are logged in to your bank in one browser tab.
Then, you visit a hacker’s website in another tab. That site secretly runs this:
<img src="https://bank.com/transfer?amount=1000&to=hacker" />
Your browser automatically sends the request using your session because you're already
logged in!
How to prevent:
Use CSRF tokens – a secret token added to every request
Use SameSite cookies so cookies aren’t sent across different sites
Ask users to confirm actions (like entering a password again)
Summary Table:
Attack Type What It Does Risk Prevention
SQL Injects harmful SQL into Database access, login Use prepared statements,
Injection input bypass validate input
Runs harmful code in Steals data, hijacks Escape input, use CSP,
XSS
browser sessions sanitize content
Tricks users into Use CSRF tokens, SameSite
CSRF Account misuse
unwanted actions cookies
Secure Coding Practices:
Secure coding practices are a set of rules and techniques that help developers write code that is
protected against hackers and bugs. Just like you lock your house doors to keep intruders out,
you also need to “lock” your code so that it can’t be misused or attacked.
Key Secure Coding Practices:
1. Validate All Input
Why: Hackers often send harmful input (like scripts or SQL commands).
What to do: Check and clean everything the user sends—forms, URLs, files.
Example: Only allow numbers for age fields, not letters or code.
2. Use Strong Authentication and Authorization
Why: Prevents unauthorized access to data or features.
What to do: Use strong passwords, multi-factor authentication, and check user roles
properly.
Example: A normal user shouldn't access admin pages.
3. Use Parameterized Queries (to prevent SQL Injection)
Why: Stops hackers from changing your SQL commands.
What to do: Use safe methods to add input into SQL queries.
Example: Use ? placeholders in SQL, not string building.
4. Use Secure Libraries and Frameworks
Why: Some libraries may have known vulnerabilities.
What to do: Always use updated and trusted versions.
Example: Avoid downloading random open-source code without checking.
5. Keep Software Updated
Why: Old versions may have bugs or security holes.
What to do: Regularly apply patches and updates to your software, libraries, and
systems.
Example: Update your web server or CMS often.
6. Encrypt Sensitive Data
Why: If someone steals data, they shouldn’t be able to read it.
What to do: Encrypt passwords, personal info, and communications.
Example: Use HTTPS, crypt for passwords.
7. Secure Session Management
Why: Attackers can hijack user sessions.
What to do: Use secure, short-lived session IDs, and set them to expire.
Example: Auto logout after inactivity.
Web Application Firewall (WAF):
A Web Application Firewall (WAF) is a security tool that sits between your website and the
internet. It monitors, filters, and blocks harmful web traffic before it reaches your website. Think
of it like a security guard standing in front of your web application.
How Does a WAF Work?
When a user tries to visit a website:
1. The request goes to the WAF first.
2. The WAF checks if the request is safe or dangerous.
3. If safe → it lets the request go to the website.
4. If dangerous → it blocks or filters the request.
What Attacks Can WAF Prevent?
Attack Type Description
SQL Injection Hackers try to run database commands
Cross-Site Scripting (XSS) Hackers try to run scripts in user browsers
Cross-Site Request Forgery (CSRF) Tricks users into doing harmful actions
File Inclusion Hackers try to upload harmful files
DDoS Attacks (basic) Too many fake requests to crash a website
Bot attacks Automated bots trying to exploit forms or login pages
Types of WAFs
Type Description Example
Network-based Installed at the network level Fast, but costly
Host-based Installed directly on the server Customizable, but uses system resources
Cloud-based Offered as a service online Easy to use, scalable
Why Is a WAF Important?
Protects your web applications from known and unknown threats.
Acts as a first line of defense before traffic reaches your app.
Helps with compliance (e.g., PCI DSS, GDPR).
Stops many automated and targeted attacks.
Real-Life Example:
A shopping website has a search box.
Without WAF: A hacker types '; DROP TABLE users; -- and deletes the user database
(SQL Injection).
With WAF: The WAF recognizes it as a dangerous pattern and blocks the request,
keeping the site safe.
Security Testing Tools:
Security testing tools help find weaknesses (vulnerabilities) in websites, apps, or systems before
hackers do. They are used by:
Ethical hackers
Security teams
Developers
These tools scan, analyze, and report on how secure your system is.
Key Security Testing Tools:
1. Burp Suite
What it is: A powerful tool for testing web application security.
Use: Intercepts traffic between the browser and website, and lets you inspect or modify it.
Features:
o Intercept requests/responses
o Scan for vulnerabilities like SQL injection, XSS, etc.
o Test login forms and sessions
Type: Manual + Automated
Good for: Deep web application testing
Example: You try logging in to a site. Burp Suite catches the request, and you can change the
username to “admin” before it goes to the server.
2. OWASP ZAP (Zed Attack Proxy)
Free & Open Source
Similar to Burp Suite but easier for beginners
Great for finding vulnerabilities automatically
Best for students and beginner ethical hackers.
3. Nikto
Use: Scans web servers for dangerous files, outdated software, and misconfigurations.
Easy to use command-line tool
Example: Nikto may find that your web server still uses an outdated and vulnerable version of
Apache.
4. SQLMap
Use: Automatically detects and exploits SQL injection flaws.
Great for testing login forms, search boxes, etc.
Example: You give SQLMap a URL, and it will test if it can break into the database using SQL
injection.
5. Wireshark
Use: Captures and analyzes network traffic in real time.
Used to see: What data is being sent across the network.
Example: You can detect if passwords are being sent without encryption (like over HTTP
instead of HTTPS).
Pro Tip:
These tools are powerful and should only be used on systems you own or have permission to
test. Unauthorized scanning is illegal.
