Skip to content

Common Http And Https Exploits For Networks


Internet browsers are used by almost everyone. Blocking web browsing completely is not an option because businesses need access to the web, without undermining web security. In this article, I want to look at common HTTP and https exploits for networks. 
To investigate web-based attacks, security analysts must have a good understanding of how a standard web-based attack works. These are the common stages of a typical web attack:
  1. The victim unknowingly visits a web page that has been compromised by malware.
  2. The compromised web page redirects the user, often through many compromised servers, to a site containing malicious code.
  3. The user visits this site with malicious code and their computer becomes infected. This is known as a drive-by download. When the user visits the site, an exploit kit scans the software running on the victim’s computer including the OS, Java, or Flash player looking for an exploit in the software. The exploit kit is often a PHP script and provides the attacker with a management console to manage the attack.
  4. After identifying a vulnerable software package running on the victim’s computer, the exploit kit contacts the exploit kit server to download code that can use the vulnerability to run malicious code on the victim’s computer.
  5. After the victim’s computer has been compromised, it connects to the malware server and downloads a payload. This could be malware or a file download service that downloads other malware.
  6. The final malware package is run on the victim’s computer.

Independent of the type of attack being used, the main goal of the threat actor is to ensure the victim’s web browser ends up on the threat actor’s web page, which then serves out the malicious exploit to the victim.

Some malicious sites take advantage of vulnerable plugins or browser vulnerabilities to compromise the client’s system. Larger networks rely on IDSs to scan downloaded files for malware. If detected, the IDS issues an alert and records the event to log files for later analysis.

Server connection logs can often reveal information about the type of scan or attack. The different types of connection status codes are listed here:

  • Informational 1xx – This is a provisional response, consisting only of the Status-Line and optional headers. It is terminated by an empty line. There are no required headers for this class of status codes. Servers MUST NOT send a 1xx response to an HTTP/1.0 client except under experimental conditions.
  • Successful 2xx – The client’s request was successfully received, understood, and accepted.
  • Redirection 3xx – Further action must be taken by the user agent to fulfil the request. A client SHOULD detect infinite redirection loops because these loops generate network traffic for each redirection.
  • Client Error 4xx – For cases in which the client seems to have erred. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the situation, and if it is temporary. User agents SHOULD display any included entity to the user.
  • Server Error 5xx – For cases where the server is aware that it has erred, or it cannot perform the request. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and if it is temporary. User agents SHOULD display any included entity to the user.

To defend against web-based attacks, the following countermeasures should be used:

  • Always update the OS and browsers with current patches and updates.
  • Use a web proxy like Cisco Cloud Web Security or Cisco Web Security Appliance to block malicious sites.
  • Use the best security practices from the Open Web Application Security Project (OWASP) when developing web applications.
  • Educate end-users by showing them how to avoid web-based attacks.

The OWASP Top 10 Web Application Security Risks is designed to help organizations create secure web applications. It is a useful list of potential vulnerabilities that are commonly exploited by threat actors.

Common HTTP Exploits

Malicious iFrames
Threat actors often make use of malicious inline frames (iFrames). An iFrame is an HTML element that allows the browser to load another web page from another source. iFrame attacks have become very common, as they are often used to insert advertisements from other sources into the page. Threat actors compromise a webserver and modify web pages by adding HTML for the malicious iFrame. The HTML links to the threat actor’s webserver. In some instances, the iFrame page that is loaded consists of only a few pixels. This makes it very hard for the user to see. Because the iFrame is run on the page, it can be used to deliver a malicious exploit, such as spam advertising, an exploit kit, and other malware.
These are some of the ways to prevent or reduce malicious iFrames:
  • Use a web proxy to block malicious sites.
  • Because attackers often change the source HTML of the iFrame in a compromised website, make sure web developers do not use iFrames. This will isolate any content from third-party websites and make modified pages easier to find.
  • Use a service such as Cisco Umbrella to prevent users from navigating to websites that are known to be malicious.
  • Make sure the end-user understands what an iFrame is. Threat actors often use this method in web-based attacks.

HTTP 302 Cushioning
Another type of HTTP attack is the HTTP 302 cushioning attack. Threat actors use the 302 Found HTTP response status code to direct the user’s web browser to a new location. Threat actors often use legitimate HTTP functions such as HTTP redirects to carry out their attacks. HTTP allows servers to redirect a client’s HTTP request to a different server.

HTTP redirection is used, for example, when web content has moved to a different URL or domain name. This allows old URLs and bookmarks to continue to function. Therefore, security analysts should understand how a function such as HTTP redirection works and how it can be used during attacks.

When the response from the server is a 302 Found status, it also provides the URL in the location field. The browser believes that the new location is the URL provided in the header. The browser is invited to request this new URL. This redirect function can be used multiple times until the browser finally lands on the page that contains the exploit. The redirects may be difficult to detect due to the fact that legitimate redirects frequently occur on the network.

These are some ways to prevent or reduce HTTP 302 cushioning attacks:

  • Use a web proxy to block malicious sites.
  • Use a service such as Cisco Umbrella to prevent users from navigating to websites that are known to be malicious.
  • Make sure the end user understands how the browser is redirected through a series of HTTP 302 redirections.

Domain Shadowing
When a threat actor wishes to create a domain shadowing attack, the threat actor must first compromise a domain. Then, the threat actor must create multiple subdomains of that domain to be used for the attacks.


Hijacked domain registration logins are then used to create the many subdomains needed. After these subdomains have been created, attackers can use them as they wish, even if they are found to be malicious domains. They can simply make more from the parent domain. The following sequence is typically used by threat actors:

  1. A website becomes compromised.
  2. HTTP 302 cushioning is used to send the browser to malicious websites.
  3. Domain shadowing is used to direct the browser to a compromised server.
  4. An exploit kit landing page is accessed.
  5. Malware downloads from the exploit kit landing page.


These are some ways to prevent or reduce domain shadowing attacks:

  • Secure all domain owner accounts. Use strong passwords and use two-factor authentication to secure these powerful accounts.
  • Use a web proxy to block malicious sites.
  • Use a service such as Cisco Umbrella to prevent users from navigating to web sites that are known to be malicious.
  • Make sure that domain owners validate their registration accounts and look for any subdomains that they have not authorized.


Over the past 25 years, email has evolved from a tool used primarily by technical and research professionals to become the backbone of corporate communications. Each day, more than 100 billion corporate email messages are exchanged. As the level of use rises, security becomes a greater priority. The way that users access email today also increases the opportunity for the threat of malware to be introduced.
It used to be that corporate users accessed text-based email from a corporate server. The corporate server was on a workstation that was protected by the company’s firewall. Today, HTML messages are accessed from many different devices that are often not protected by the company’s firewall. HTML allows more attacks because of the amount of access that can sometimes bypass different security layers.

The following are examples of email threats:

  • Attachment-based attacks – Threat actors embed malicious content in business files such as an email from the IT department. Legitimate users open malicious content. Malware is used in broad attacks often targeting a specific business vertical to seem legitimate, enticing users working in that vertical to open attachments or click embedded links.
  • Email spoofing – Threat actors create email messages with a forged sender address that is meant to fool the recipient into providing money or sensitive information. For example, a bank sends you an email asking you to update your credentials. When this email displays the identical bank logo as mail you have previously opened that was legitimate, it has a higher chance of being opened, having attachments opened and links clicked. The spoofed email may even ask you to verify your credentials so that the bank is assured that you are you, exposing your login information.
  • Spam email – Threat actors send an unsolicited email containing advertisements or malicious files. This type of email is sent most often to solicit a response, telling the threat actor that the email is valid and a user has opened the spam.
  • Open mail relay server – Threat actors take advantage of enterprise servers that are misconfigured as open mail relays to send large volumes of spam or malware to unsuspecting users. The open mail relay is an SMTP server that allows anybody on the internet to send mail. Because anyone can use the server, they are vulnerable to spammers and worms. Very large volumes of spam can be sent by using an open mail relay. It is important that corporate email servers are never set up as an open relay. This will considerably reduce the number of unsolicited emails.
  • Homoglyphs – Threat actors can use text characters that are very similar or even identical to legitimate text characters. For example, it can be difficult to distinguish between an O (upper case letter O) and a 0 (number zero) or a l (lower case “L”) and a 1 (number one). These can be used in phishing emails to make them look very convincing. In DNS, these characters are very different from the real thing. When the DNS record is searched, a completely different URL is found when the link with the homoglyph is used in the search.

Just like any other service that is listening to a port for incoming connections, SMTP servers also may have vulnerabilities. Always keep SMTP software up to date with security and software patches and updates.

To further prevent threat actors from completing their task of fooling the end-user, implement countermeasures. Use a security appliance specific to email such as the Cisco Email Security Appliance.

This will help to detect and block many known types of threats such as phishing, spam, and malware. Also, educate the end-user. When attacks make it by the security measures in place, and they will sometimes, the end-user is the last line of defence. Teach them how to recognize spam, phishing attempts, suspicious links and URLs, homoglyphs, and never open suspicious attachments.

Web-Exposed Databases

Web applications commonly connect to a relational database to access data. Because relational databases often contain sensitive data, databases are a frequent target for attacks.
Code Injection
Attackers are able to execute commands on a web server’s OS through a web application that is vulnerable. This might occur if the web application provides input fields to the attacker for entering malicious data. The attacker’s commands are executed through the web application and have the same permissions as the web application. This type of attack is used because often there is insufficient validation of input. An example is when a threat actor injects PHP code into an insecure input field on the server page.SQL Injection
SQL is the language used to query a relational database. Threat actors use SQL injections to breach the relational database, create malicious SQL queries, and obtain sensitive data from the relational database.
One of the most common database attacks is the SQL injection attack. The SQL injection attack consists of inserting a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data, execute administration operations on the database, and sometimes, issue commands to the operating system.


Unless an application uses strict input data validation, it will be vulnerable to the SQL injection attack. If an application accepts and processes user-supplied data without any input data validation, a threat actor could submit a maliciously crafted input string to trigger the SQL injection attack.


Security analysts should be able to recognize suspicious SQL queries in order to detect if the relational database has been subjected to SQL injection attacks. They need to be able to determine which user ID was used by the threat actor to log in, then identify any information or further access the threat actor could have leveraged after a successful login.

Client-side Scripting

Cross-Site Scripting
Not all attacks are initiated from the server-side. Cross-Site Scripting (XSS) is where web pages that are executed on the client-side, within their own web browser, are injected with malicious scripts.
These scripts can be used by Visual Basic, JavaScript, and others to access a computer, collect sensitive information, or deploy more attacks and spread malware. As with SQL injection, this is often due to the attacker posting content to a trusted website with a lack of input validation. Future visitors to the trusted website will be exposed to the content provided by the attacker.
These are the two main types of XSS:
  • Stored (persistent) – This is permanently stored on the infected server and is received by all visitors to the infected page.
  • Reflected (non-persistent) – This only requires that the malicious script is located in a link and visitors must click the infected link to become infected.

These are some ways to prevent or reduce XSS attacks:

  • Be sure that web application developers are aware of XSS vulnerabilities and how to avoid them.
  • Use an IPS implementation to detect and prevent malicious scripts.
  • Use a web proxy to block malicious sites.
  • Use a service such as Cisco Umbrella to prevent users from navigating to websites that are known to be malicious.
  • As with all other security measures, be sure to educate end-users. Teach them to identify phishing attacks and notify infosec personnel when they are suspicious of anything security-related.

Action Point
PS: If you would like to have an online course on any of the courses that you found on this blog, I will be glad to do that on an individual and corporate level, I will be delighted to do that because I have trained several individuals and groups and they are doing well in their various fields of endeavour. Some of those that I have trained include staff of Dangote Refinery, FCMB, Zenith Bank, and New Horizons Nigeria among others. Please come on Whatsapp and let’s talk about your training. You can reach me on Whatsapp HERE. Please note that I will be using Microsoft Team to facilitate the training. 

I know you might agree with some of the points that I have raised in this article. You might not agree with some of the issues raised. Let me know your views about the topic discussed. We will appreciate it if you can drop your comment. Thanks in anticipation.


Fact Check Policy

CRMNUGGETS  is committed to fact-checking in a fair, transparent and non-partisan manner. Therefore, if you’ve found an error in any of our reports, be it factual, editorial, or an outdated post, please contact us to tell us about it.


Fact Check Policy

Leave a Reply

Your email address will not be published. Required fields are marked *