A penetration tester reports an application is only utilizing basic authentication on an Internet-facing application. Which of the following would be the BEST remediation strategy?
PenTest+ Practice Tests Book
A. - In this scenario, the tester should recommend that the client enable HTTP Strict Transport Security (HSTS). The HSTS response header lets a website tell browsers that it should only be accessed using HTTPS, instead of using HTTP. It is an opt-in security enhancement that is specified by a web application through the use of a special response header. Once a supported browser receives this header, that browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS.
EXACTLY!! Like this ---However, the attacker can take advantage of the fact that the site is also available over HTTP. The attacker can send the link to the HTTP version of the site to the user. The user clicks the link and the HTTP request is generated. Since HTTP traffic is sent in plaintext, the attacker eavesdrops on the communication channel and reads the authentication cookie of the user. Can we allow this cookie to be sent only over HTTPS? If this was possible, we would prevent the attacker from reading the authentication cookie in our story. It turns out that it is possible and a secure flag is used exactly for this purpose — the cookie with a secure flag will only be sent over an HTTPS connection.
HSTS is "opt-in" on client side!! not saying you are definitely wrong here but read above comments I made...MY OPINION is the Sec Cookie would be better
there is no single word relating to http/unencrypt. why did you all make such assumption. we cant even tell "basic authentication" was refered to website legitimate or user authetication.
https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
A must be the BEST remediation strategy here, a secure cookie flag will probably not prevent a man-in-the-middle attack
For what it's worth I'm following the same logic as who__cares. I'm sick of trying to get into the mindset of comptia but you end up just trying to find the smallest clues in the questions. HSTS is opt-in so is pointless if you can get a victim to use port 80. And the question makes clear that it will continue to use port 80. As the question states that the issue is authentication and not complete encryption of all traffic, then protection sessions cookies is the most important thing. If I get this question I'm going with B
https://resources.infosecinstitute.com/topic/securing-cookies-httponly-secure-flags/
basic auth is username/password - however it is plain text in HTTP
to use the HSTS header you must set up the web site to use HTTPS://
question is does require answer C: encrypt the communications channel with SSL/TLS not sure if the header will work unless you turn https on
NO NO NO...not so fast! However, the attacker can take advantage of the fact that the site is also available over HTTP. The attacker can send the link to the HTTP version of the site to the user. The user clicks the link and the HTTP request is generated. Since HTTP traffic is sent in plaintext, the attacker eavesdrops on the communication channel and reads the authentication cookie of the user. Can we allow this cookie to be sent only over HTTPS? If this was possible, we would prevent the attacker from reading the authentication cookie in our story. It turns out that it is possible and a secure flag is used exactly for this purpose — the cookie with a secure flag will only be sent over an HTTPS connection.
D. Sanitize invalid user input?
Even if you enable HTTP Strict Transport Security, the application is still using basic authentication. The problem is with the application, not the communication channel.
Basic authentication may not stop an sql injection.
Like injection, broken authentication has not changed position in the OWASP top 10 vulnerability list since 2013. A misconfigured authentication system could allow attackers to impersonate legitimate users by compromising passwords, session tokens, etc. The technical impact is severe. If you could log in as anybody else, you could potentially have access to all resources on their website or application.
Remediation Measures: Use a combination of tactics to mitigate your risks:
Implement multi-factor authentication (MFA).
Avoid using default credentials.
Implement strong password policies.
Use controls such as delayed failed logins, randomized session IDs, session timeouts, etc. as preventive measures.
Be sure to log all failed login attempts.
Let’s consider the following scenario to answer this question. The site is available over HTTP and HTTPS. Moreover, let’s assume that there is an attacker in the middle of the communication channel between the browser and the server. The cookie sent over HTTPS can’t be eavesdropped.
However, the attacker can take advantage of the fact that the site is also available over HTTP. The attacker can send the link to the HTTP version of the site to the user. The user clicks the link and the HTTP request is generated. Since HTTP traffic is sent in plaintext, the attacker eavesdrops on the communication channel and reads the authentication cookie of the user. Can we allow this cookie to be sent only over HTTPS? If this was possible, we would prevent the attacker from reading the authentication cookie in our story. It turns out that it is possible and a secure flag is used exactly for this purpose — the cookie with a secure flag will only be sent over an HTTPS connection.
I'm not sure you totally follow how HSTS works. https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
It's made to combat MITM attacks. So this internet facing app is a risk, they turn on HSTS, now regular users that visit the site are given a directive to only work over HTTPS and this is saved to their browser. You the attacker send them an HTTP link, when they open it, it immediately uses HTTPS instead. There is no facility for the attacker to change the user's browser which has already stored the HSTS flag for that website. There is an edge case for a user that maybe hasn't logged into the site since the HSTS was enabled but if the basic auth cannot be changed in the web app, this is a good mitigation. With this the attacker needs a user that hasn't logged in since the HSTS was enabled and one that falls for the phish, the most time that passes after enabling HSTS the harder it becomes to find that vulnerable user.
An easy one to test this with is google, make yourself a link to google with http and turn on the web dev tools->Network, filter to http:// and you'll see nothing, other sites use a single 302, but google uses HSTS, you can find it in your browser, in fact, in Chrome it is embedded in the application, much to the chagrin of someone wanting to do SSL Inspection for content filtering in a network.
upvoted 1 times
...
...
...
...
...
...
This section is not available anymore. Please use the main Exam Page.PT0-001 Exam Questions
Log in to ExamTopics
Sign in:
Community vote distribution
A (35%)
C (25%)
B (20%)
Other
Most Voted
A voting comment increases the vote count for the chosen answer by one.
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one.
So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
mr_robot
Highly Voted 5 years, 3 months agoLeonar
5 years agowho__cares123456789___
4 years, 5 months agowho__cares123456789___
4 years, 5 months agomiabe
Most Recent 3 years agoCock
3 years, 5 months agoenergystar
3 years, 5 months agomattlai
3 years, 5 months agoDave1212
4 years, 2 months agoBob67
4 years, 3 months agoRedbyNight
4 years, 5 months agoTestBanger
4 years, 8 months agojon34thna
5 years, 4 months agowho__cares123456789___
4 years, 5 months agoD1960
5 years, 4 months agoD1960
5 years, 3 months agowho__cares123456789___
4 years, 5 months agowho__cares123456789___
4 years, 5 months agodyers
4 years, 2 months agodyers
4 years, 2 months ago