New answers tagged http
2
If the site sends the HSTS header in the HTTP response, than that is against the RFC.
And the RFC also states, that you "SHOULD" 301 the client to HTTPS and I honestly don't see any reason not to.
2
The difference is simple: the computer user chooses which website address to type into their browser. They do not choose which website addresses that site then tries to exchange information with.
That key distinction means we need protections on the latter, but not the former.
Of course, an equivalent of that protection for the former would mean you could ...
25
And how can a web server distinguish between requests coming from a script and coming from a user?
It doesn't. The same origin policy is enforced by the browser, not the server.
The purpose of the SOP isn't to protect the server itself. Instead it's to protect confidential information which the server wishes to share with the user, but not to share with ...
1
However, the latter one violates the Same Origin Policy (SOP) if the server runs on a remote domain.
No, it does not necessarily. Otherwise, XMLHttpRequest would be useless, as you observed.
The point is that the HTTP request triggered by the JS program by means of XMLHttpRequest has to point to the server which delivered the website, otherwise it violates ...
-1
Yes.
In information security circles, the HEAD method, while admittedly useful in some situations, allows requests to bypass security constraints.
It should be disabled
Nessus comments on the security issues with HEAD.
OWASP reports how it can be used to create new users on a system remotely.
13
The simple answer to your question is that "requests to display a web page" are what set the origin, so obviously they cannot violate same-origin policy. Things that happen within a page (such as JS execution and notably XHR/Fetch) are subject to various restrictions due to same-origin policy, but top-level navigation is always allowed*.
* Iframes ...
13
If one enters a URL in the browser one starts with a new empty origin, i.e. no domain and port belong to the origin initially. Everything can be put into a window/tab with an empty origin and once it is put there the origin changes depending on where the data came from.
If one instead calls a HTTP request from inside a loaded web page, one starts with a non-...
5
Attacker-controlled javascript within browser sandbox
If you don't have any sensitive or valuable data or inputs within that site, the main risk IMHO is that since it uses HTTP, an attacker can impersonate the site owner and inject malicious javascript. The damage that it can do is limited by the browser sandbox, but it does create at least the following ...
26
Yes, there is a risk.
HTTPS ensures not just confidentiality, but also integrity and authenticity. As such, an attacker could hijack the connection between you and the server and inject malicious JavaScript into your session.
How likely is that to happen?
Depends on how you connect to the server. If you are in your own home, then the likelihood is not very ...
-3
https is used to encrypt data such as credit card information or other sensitive data, it is always possible that somebody could be a man in the middle and record your mouse movements but i don't think this should be a cause for concern, what can an attacker possibly do knowing you moved your mouse around in a partcular way? i doubt anybody would waste their ...
3
According to online reports (bug tracker, reddit) and tweets from the authors it appears that:
The updates are signed by PGP (good)
The version is checked to avoid downgrade attacks (good)
The signature use an old 1024 bit DSA key, never renewed (bad)
We can conclude:
This mechanism is not at the sate of the art because of a deprecated signing algorithm, ...
28
Current situation
It is true that, as of Oct 2020, Google does not have HSTS on google.com, but only on www.google.com, and performs redirection first to www and then to https://. Even if there was a HSTS header on google.com, the browser would not see it and be able to cache it. Only www.google.com is protected by HSTS.
Best practices
It is also recommended ...
2
Including the signature in the session token makes it hard to guess.
Assume your token includes a signature and looks like this:
user_id:12,signature:5c9597f3c8245907ea71a89d9d39d08e
Of course, the first parts are easy to guess. The signature part is hard to guess. But what matters is whether the whole token is hard to guess, and since the signature is ...
1
Putting an auth cookie value in the URL is a bad practice because it can be retrieved in the following locations (whether or not your are using https):
Referer Header
Web Logs
Shared Systems
Browser History
Browser Cache
Shoulder Surfing
So there is more risk that a third party impersonate the user session.
You should consult the OWASP about this case : ...
0
If the cookie contains any sensitive information or session information, you will not want that information inside of the URL. Users may take screenshots of URLs, paste URLs, or inadvertently print a URL when they print pages. If the URL were to contain, say, a session ID, then an attacker could steal that session.
If you have to set the cookie based off ...
3
So with https, someone can still see what website I visited, but not which pages within that website I visited, correct?
Kind of. HTTPS is build on top of TLS. Within the TLS handshake the client announces to the server which domain it wants to access. This is needed since there can be several domains with their own certificates on the same server IP ...
3
You are confusing "confidentiality" with "anonymity". Encryption makes it so that the content of your communication cannot be known (confidentiality). But it does not hide who you are communicating with.
So, encryption is not the tool you need to use.
You are looking for some way for your traffic to be obscured. A VPN and Tor can do that, ...
0
"why isn’t the whole process of connecting to a website - from when I
start typing the website name on the browser - encrypted?"
Because the server and browser need to exchange the same decryption key so that only they can decrypt the traffic.
0
Given the fact that you are posting this question on security.stackexchange.com, I assume that you're interested in the security implications of "Is it possible to read these cookie values using any methods?".
In addition to what Sjoerd correctly states, it's worth mentioning that in case that the httponly flag has not been set on the cookie, a ...
2
Generally, reading cookies by other sites or by a man-in-the-middle attacker is not possible, if the site is configured correctly.
Cookies are not strictly bound to the same-origin policy. Depending on their settings, they may be shared with subdomains and superdomains. If cookies settings are not marked as secure, cookies set over HTTPS are also sent over ...
1
According to here, this issue will show up if you have paranoia enabled. Did you purposefully enable paranoid scans?
Paranoid scans turn up with a lot of weird plugins like these. Another example of paranoia false positives I have seen was something along the lines of "Port 4444 is open, therefore there is a backdoor on this machine," which isn't ...
Top 50 recent answers are included
