43 lines
3.2 KiB
TeX
43 lines
3.2 KiB
TeX
\section{Mitigation}
|
|
\label{sec:mitigation}
|
|
|
|
There are a few things that can be changed in order to avoid a \textit{\gls{http} Response Splitting} attack.
|
|
|
|
\subsection{User entries}
|
|
\label{subsec:mitigation_entries}
|
|
|
|
One of the most used vulnerabilities is the data that can be given by users of a system. It is very important to consider them as not secure at all when they are received by the system.
|
|
|
|
In our case, it is a malicious input that is interpreted. It is not a misconfiguration of the \gls{http} protocol neither a problem with the host system. The sysadmin just has to sanitize inputs situated in the \gls{url}s, and this can be done in the \gls{cgi} environment.
|
|
|
|
Inputs should be validated, sanitized and escaped to be sure that they would not be harmful.
|
|
|
|
A validation\footnote{\url{https://bit.ly/35psyfb}} aims to confirm the good syntax of the input, as well as its semantic value. There is a lot of tools, such as library or \gls{framework}s that are available for such goal.
|
|
|
|
A sanitized input ensure that the data is conform to the configuration of a system. Unwanted and dangerous characters must be eliminated, replace or encoded to avoid malicious actions. In our case, the \gls{crlf} characters should have been sanitized. This is close to the escaping concept, that aims to annihilate special characters that could be interpreted by a system.
|
|
|
|
A white-listing of the \gls{url}s can be done. This is more efficient than a black-listing, because it is less prone to words oversights. This way, if an input does not correspond to our database of authorized words, the request could be blocked.
|
|
|
|
Those manipulations must not be done on the client-side! They are too easy to bypass. Such mechanisms must be defined on the server-side.
|
|
|
|
\subsection{Limit cache hits}
|
|
\label{subsec:mitigation_cache}
|
|
|
|
One problem of the Web server was that the cache accepted our forged response easily. The reverse proxy that acts as the caching system should host various rules to limit the acceptation of caching when too generalized. \textit{Cloudflare} explained\footnote{\url{https://bit.ly/3eTyeBx}} how to avoid such attacks.
|
|
|
|
\newpage
|
|
|
|
\subsection{Securise \gls{cookie}s}
|
|
\label{subsec:mitigation_cookies}
|
|
|
|
The \gls{cookie}s were readable by a \gls{javascript} code, and not exchanged in a secured transmission such as \gls{tls}. This is caused by the bad configuration of the Web server, that does not define the \gls{http} \textit{Secure} and \textit{httpOnly} headers.
|
|
|
|
\subsection{Limit system banners}
|
|
\label{subsec:mitigation_banners}
|
|
|
|
A system should not expose its information across the Internet. When doing the \textit{Nessus} scan, we found the version of \textit{Linux} kernels and the softwares used by Web servers. Although those data did not help us during this challenge, this is not a good practice.
|
|
|
|
\subsection{Do technology watch}
|
|
\label{subsec:mitigation_watch}
|
|
|
|
Finally, for every information system, sysadmins should proceed to technology watch through vulnerabilities databases, such as the \textit{CVE}\footnote{\url{https://cve.mitre.org/cve/}} database or the \textit{CWE}\footnote{\url{https://cwe.mitre.org/}} one. The \textit{OWASP Top 10}\footnote{\url{https://owasp.org/www-project-top-ten/}} also brings a lot of tips to prevent most used attacks nowadays. |