Principles of Web
Application
Security
W6 - WEB SERVER VULNERABILITIES
Thanks to Dr Wesam Almobaideen for the lecture notes
Well Known Web Servers
We will concentrate on the actual web server implementation.
• There have been three main web servers
• Apache (1995)
• IIS (1995)
• Ngnix (2002)
• They are, nowadays, well-established and highly secure web servers.
• Recently, we have other web servers that have some vulnerabilities.
Example of Web Server
Vulnerability
Caching issues:
• You retrieved your banking page, which contains your social security number and
other sensitive info.
• If this is cached on a local intermediary or other intermediary caching system on
the internet, then it is possible for others to get access to your information through
this cached version of the banking web page.
• This can be controlled via ‘Cache-Control’ headers. Whether intermediaries are
complying with the ‘should not‘ specification of “no caching” cache control or not is
another issue.
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching
Poisoning the cache (HTTP Response
Splitting)
•Header splitting allows the attacker to inject headers. The key to the attack is ability for an attacker to
modify the message headers. HTML is stateless, so neither the web server nor the browser has any
problem with this seemingly odd behavior.
•The injected header could be a new location header message or an entirely additional response
header, which could confuse the caching system into sending that added response message instead of
the original.
•In other words, it takes place:
1. where the server script embeds user data in HTTP redirection response headers (HTTP status code 3xx) OR
2. when the script embeds user data in a cookie value or name of Set-Cookie in a response
•Similar to Parameter Tampering
•It works well with https as well since it works in entry points.
•It is done via 2 backtoback %0d%0a, which will be decoded into a CRLF.
•This depends to a large extent on the actual implementation of the web caching proxy.
Poisoning the cache (HTTP Response
Splitting) – Normal case
• For example, consider the following JSP page (let’s assume it is located in /redir_lang.jsp)
<% response.sendRedirect("/by_lang.jsp?lang="+ request.getParameter("lang")); %>
When invoking /redir_lang.jsp with a parameter lang=English, it will redirect to /by_lang.jsp?lang=English.
• A typical response:
HTTP/1.1 302 Moved Temporarily
Date: Wed, 24 Dec 2003 12:53:28 GMT
Location: http://10.1.1.1/by_lang.jsp?lang=English
Server: WebLogic XMLX Module 8.1 SP1 Fri Jun 20 23:06:40 PDT 2003 271009 with
Content-Type: text/html
Set-Cookie: JSESSIONID=1pMRZOiOQzZiE6Y6iivsREg82pq9Bo1ape7h4YoHZ62RXjApqwBE!1251019693; path=/ Connection: Close
<html><head><title>302 Moved Temporarily</title></head>
<body bgcolor="#FFFFFF">
<p>This document you requested has moved temporarily.</p>
<p>It's now at <a href="http://10.1.1.1/by_lang.jsp?lang=English">http://10.1.1.1/by_lang.jsp?lang= English</a>.</p>
</body>
</html>
Poisoning the cache (HTTP Response
Splitting) – Abnormal case
•Instead of sending the value English,
1. We send URL-encoded CRLF sequences to terminate the current response
2. Add malicious code
/redir_lang.jsp?lang=foobar%0d%0aContentLength:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d
%0aContentType:%20text/html%0d%0aContent-Length:%2019%0d%0a%0d%0a<html>Attack</html>
Red is header of the inserted malicious response. Green is body.
https://www.url-encode-decode.com/
Poisoning the cache (HTTP Response
Splitting) – Abnormal case
HTTP/1.1 302 Moved Temporarily
Date: Wed, 24 Dec 2003 15:26:41 GMT
Location: http://10.1.1.1/by_lang.jsp?lang=foobar
Content-Length: 0
HTTP/1.1 200 OK
Content-Type: text/html
This is the attack content!
Content-Length: 19
<html>Attack</html>
Server: WebLogic XMLX Module 8.1 SP1 Fri Jun 20 23:06:40 PDT 2003 271009 with
Content-Type: text/html
Set-Cookie: JSESSIONID=1pwxbgHwzeaIIFyaksxqsq92Z0VULcQUcAanfK7In7IyrCST9UsS!1251019693;
path=/
Connection: Close
Cache Poisoning second scenario
Since there is 1 request but 2 responses, servers save 2 nd one only. But Cache is poisoned. Proxy servers are used as cache as
well. They use their cache for sending responses to other client requests.(also, victims have local caches).
New Web Servers
Some of the historical problems, such as header splitting and injection, are becoming again a
serious problem with the newly emerging web servers.
•Node.JS, Flask, and others come with their own web server which are not so elaborated as
apache or IIS and so security issues could re-emerge. Other security issues that could emerge in
various versions of all web servers are:
• Buffer overflow
• DOS
• Bypassing certain permission or security features
• Sensitive information disclosure
Where are the vast majority of
vulnerabilities
These are not in the core implementation of the web server but rather in Modules that add
support for various issues such as:
• Proxying (mod_proxy)
• SSL/TLS (mod_ssl)
• Server side languages (mod_php, mod_cgi, mod_lua)
• Processing capabilities (mod_deflate, mod_rewrite)
Why do we need server side P.L.
(Procedural languages)
• We need to serve clients with things that are not just HTML files
• We need to get parameters at the server side according to which we generate the HTML page
that should be sent as a response. This allows for more dynamic and interactive web contents
that is based on who is the client.
• To Respond to queries from users or from HTML forms.
• We can store information in a database whether relational or other types.
• Carrying out security procedures without the intervention of the client which can delay this
process and allows for by passing authentication procedures.
• Reduces the reliance on the browser support for certain capabilities.
Security issues with server side
P.L.
• Parameters can control the execution of code at the server side and this code must be well written in
order to avoid the exploitation of this code by attackers.
• HTTP is not originally designed to support server side coding and this brought us to the addition of
modules which could contain serious vulnerabilities based on
• The inherent vulnerability of the language itself
• The implementation of the code such as privilege issues.
• The flow of whole process --------------------------------
PHP history
• PHP was first designed in 1994 and written in C. So there are fundamental problems with the language
of implementation such as buffer overflow.
• It was a set of CGI scripts for resume information tracking.
• PHP 2.0 (1995) different to a great extent from today’s PHP
• PHP 3.0 (1997) is also very different from PHP. PHP now has been reached after 7 rewrites of the core
functionalities.
• PHP 4 referred to as the modern PHP
• PHP 5 (2004) stable release in (2008). Almost 30% of PHP market share in 2021.
• PHP total market share is thought to be 60% (2016)
• Now it has a market share of 33.6% (2024)
PHP 5 Security
In PHP 5 some of the poor design issues regarding security have been
remediated such as:
• Register Globals are made off. It allows the overwrite of variables by passing
them as parameters.
• Magic quotes: Allow the escape of quotes provided by users. But what if you
escape an escape, then the quote is activated again.
• Y2K_compliance option for cookies which caused security problems.
• Allow-call-Time pass by reference: allows the passing of parameters by
reference which is very dangerous at the server side program.
PHP 7 vs. PHP 5
1. PHP 5 uses Zend II but PHP 7 uses a brand new model of engine called PHP-NG or
Next Generation which improves the performance as much as twice with optimized
memory usage.
2. PHP 7 allows programmers to declare the return type of the functions as per the
expected return value.
3. PHP 7 has eased error handling as it has replaced several major errors with
exceptions that can be handled effortlessly.
4. Anonymous class support: faster, used once, and not part of the documentation
5. New Operator: It is called spaceship operator that comes with the notation <=> and
in the technical term, you can call it combined comparison or three-way
comparison operator.
Hardening the web server configurations
How to manage a web server?
•Dedicated web-based management services are available, such as cPanel, which allows for accessing the web
document as well as managing other related services such as the mail service, authentication services, and
Firewalls.
• This is a double-edged sword since it makes management easier but at the same time increases the attack
surface.
• Accessing a file of a web hosting server using such services can be done through SSH, windows shares, or
sometime with FTP!!!
• Shared hosting and virtual hosting are problematic when it comes to security. Ensure that one won’t be
able to access other’s files.
• In such environment, configuration files are usually allowed to be shared. This introduces some problems
if they used to disable web services belonging to other users, to add authentication to other parties,
prioritize resources or disable access to these resources.
• Uploaded files are hosted in the temp directory, which could be shared for more than one user!!
https://www.hostinger.com/tutorials/what-is-cpanel
Automated publishing-Shared web
resources
• The use of Docker is kind of work around shared configuration files
problem even though they come with a little bit of increased
resources utilization overhead.
• Using PHP on the server side also could allow the sharing of session
and uploaded files stored, usually in the temp directory. This could
allow the attacker to reach the same storage space of the victim and
consequently allow him to access others’ sensitive data.
Hardening Web Servers -Information
Disclosure
• The (Server: …) header message field is added by default in most known web servers and
releases too much information to attackers.
• It conveys the server name, version, and extensions and modules that are being used. This should be
locked down to the minimum level.
• Sometimes servers are configured by default to enable directory indexing which gives a list
of directories and files much like (ls) Unix command.
• This could allow the attacker to discover hidden files and directories as well as other secure
information about the file structure of the web server.
• Server side languages tend to display debugging information. Stack traces and detailed
error messages should not be seen by attackers.
Hardening Web Servers
• Deactivate functions that are not used, such as trace, delete and put.
• Disable all versions of HTTP that are not secure and are not needed such
as HTTP/0.9 and HTTP/1.0
• Disable any non HTTP service that is not needed such as web socket.
• Allow the addition of headers that increase the security level of your web
server such as XSS header protections.
• Disable any module that might not be in use or needed such as
mod_PHPor mod_SSLor …
Hardening Web Servers: Logging
• https://httpd.apache.org/docs/trunk/logs.html Apache common log
format. Notice the warning there.
• Attacker can target the log themselves by LOG INJECTION. A script
can be passed through a log.
• Attacker can manipulate the log so that it appears as information
that does not exist in the first place.
Log Forging Example
1. Read an integer value from a request object 2. if an attacker submits the string
“twenty-one%0a%0aINFO:+User+logged+out
%3dbadguy”
If a user submits the string “twenty-one” for val
References
https://learn.microsoft.com/en-us/windows-hardware/drivers/network/overview-of-ndis-ports
https://cyberhoot.com/cybrary/application-proxy/
https://research.aimultiple.com/socks5-proxies/
https://blog.coderco.io/p/the-role-of-reverse-proxies-in-modern
https://geonode.com/blog/beginners-guide-to-socks5-proxies
https://hackersvanguard.com/sometimes-you-just-have-to-proxy-your-socks-off/
https://en.wikipedia.org/wiki/TLS_termination_proxy
https://research.aimultiple.com/forward-vs-reverse-proxy/
https://www.ietf.org/proceedings/interim-2014-sidr-01/slides/slides-interim-2014-sidr-1-0.pdf
https://www.youtube.com/watch?app=desktop&v=CT4xaXLcnpM
