Skip to main content

Posts

Showing posts with the label English

Secure Apache from clickjacking attacks using X-FRAME-OPTIONS y Content Security Policy (CSP) frame-ancestors HTTP headers

In an earlier post , we wrote about clickjacking attacks: its definition, how to know if a website or a web application is vulnerable and different protection techniques [ 1 ]. In this post we will demonstrate how to configure the Apache web server in order to protect it against these kind of attacks. As we have seen, there is not a unique mechanism to protect Apache from all the possible clickjacking attacks, but a good alternative is the use of the  X-Frame-Options  header[ 2 ] together with the frame-ancestors directive of the  Content Security Policy (CSP) header [ 3 ]. Luckily, Apache can be configured to add both headers to all its HTTP/HTTPS responses in order not to depend on the programmer of the website or the web application to do it inside their code. To make Apache add these two HTTP headers in Debian-based distributions (Ubuntu included) the following has to be done: Step 1 : Activate the headers module in the Apache configuration, if not active alre...

Clickjacking attacks: definition and mitigation mechanisms

What is a clickjacking attack and how is it launched? Clickjacking attacks are also known as user interface (UI) redress attacks and belong to the category of user interface misrepresentation of critical information [0] . In order to launch a clickjacking attack the attacker creates a malicious website by combining multiple layers (transparent and opaque) so as to deceive users who think are clicking a link inside the website they are viewing when in fact they are clicking an invisible superior element [1] . This same technique can be used to “hijack” the pressed keys when the user types in a text field of the malicious website. For the purpose of preparing a website with these characteristics, the attacker needs the following: Be able to embed inside the malicious website the content of another website or web application (the victim of the attack) whose users are to be deceived. This can be achieved by using HTML frame or iframe tags. For example, the website of a bank could...

Google Dorking: How to verify the security of your website or web application using Google

Google Dorking (also known as Google Hacking) is a resource often used by cybersecurity specialists. It consists in using the basic and advanced operators supported by Google to perform very specific searches to detect vulnerabilities or sensitive information incorrectly published on a website or a web application. Firstly, to clarify how these operators can be used in this way, a list of basic search operators supported by Google is detailed below  [1] : Operator Example search Meaning "" "MySQL dump 10.13" Exact search. It only shows results which contain the exact expression  MySQL dump 10.13 . AND computer AND security Logical operator AND. Used by default if no other operator is specified. It shows results with the term  computer and also the term  security . OR computer OR security Logical operator OR. It shows results which contain the term  computer ,  security or both. | computer | securit...

How to disable weak SSH cipher and MAC algoritms in Ubuntu 14.04 (or any other GNU/Linux distro)

If you still have an Ubuntu 14.04 LTS (or any other old distro) in a production environment, most likely the SSH service is accepting weak cipher and MAC algorithms. At present, the cipher algorithms considered to be weak are: CBC (3des-cbc, aes128-cbc, aes192-cbc, aes256-cbc, blowfish-cbc, cast128-cbc, and rijndael-cbc@lysator.liu.se) [1]   [2] and RC4 (arcfour, arcfour128, and arcfour256) [3] . While the MAC algorithms in this condition are: MD5 (hmac-md5, hmac-md5-96, hmac-md5-96-etm@openssh.com, and hmac-md5-etm@openssh.com) and 96-bit algorithms (hmac-sha1-96 and hmac-sha1-96-etm@openssh.com). Now, how is it possible to know if these algorithms are being used by the SSH service in any given GNU/Linux system? Simply by executing the following command within the system we want to verify (assuming the SSH service is listening on port TCP/22): # ssh -vvv localhost -p 22 The previous command should show an output similar to this one: Here, all the algorithms supported ...