SQL Injection & XSS Attacks Explained: Web Application Security Basics
HELLO FRIENDS
WELCOME TO MY CYPHER LOG
Guys in this blog I am going to explain about web application attacks which are SQLi and XSS, don't overthink it's not that much complicated actually I too do that, I will try my best to explain these things how I understood it.
SQLi - structured query language injection
We all know about SQL which is used to communicate with the database right. but attackers use this to inject their malicious code into the data base to do what they want.
Actually SQLi happens when an attacker tricks a web application into sending malicious commands to the data base. The application blindly trusts the input and executes the command.
here is an example for SQL injection
SELECT * FROM users WHERE username = '[INPUT]' AND password = '[INPUT]'
If a normal user types admin and password123, the database checks for that exact match.
But if an attacker types ' OR 1=1 -- into the username field, the query becomes:
SELECT * FROM users WHERE username = '' OR 1=1 --' AND password = ''
The ' closes the username field early.
OR 1=1 is a condition that is always true.
The -- comments out the rest of the line (including the password check).
Investigators use some techniques to identify SQL injection
They would check things like web server logs, database logs and also web application firewall alerts.
In web server logs they would analyse Apache / Nginx access logs in this they look for strange characters in the URL or post request like union, select, drop.
In data base logs they would check for unusual massive SELECT queries or sudden DROP TABLE commands executed at odd hours.
Then they would also check the web application firewall ( WAF ) alerts, it acts like a log note which not only log authorised access it also logs the blocked SQLi attempts and it will provide the attacker's IP address.
Here we came to the next part which is
Cross site scripting ( XSS )
This type of attacks are also slightly same like the SQL injection,
This XSS occurs when an attacker injects a malicious client side script into a web page, this will be viewed by the users and our browsers usually trust the legitimate platforms right, by this the malicious script will execute into our browser.
This will steal session cookies and allowing the attacker to hijacking the victim's logged in account,
It can redirect the user to a fake phishing sites.
Actually it's highly dangerous, it had three variants.
3 TYPES OF XSS
Stored or persistent XSS
In this variant the script will live in that website rent free for its lifetime, and it will infect every person who view that page.
Reflected or Non-persistent XSS
It's less dangerous than the persistent XSS because it won't infect our browser itself they need our action to get into our browser, These malicious scripts would be embedded in URLs, attackers often use phishing to trick us.
DOM based XSS
In this the vulnerability exists in the client side code rather than the server. It will affect our browsers when we process the document object model.
Here is our best part, how can we identify it
Investigators would always search for the malicious script in the application's data base for stored XSS.
To identify reflected XSS they would analyse the URLs that was sent to the victim and they recover it from the victim's browser history on the phishing e-mail.
So that's it guys, I hope you guys understand it well. Stay tuned for the interesting topics in cyber.
If you want study guides to know more about this topic you can get through this link!

Comments
Post a Comment