Tag Info

Hot answers tagged

17

This client behavior is prohibited by section 8.1 of the RFC: If an HTTP response is received over insecure transport, the UA MUST ignore any present STS header field(s). The spec prohibits severs from sending insecure HSTS directives and clients from processing insecure HSTS directives. This ensures that a faulty implementation in either a server or ...


12

Looks like the certificate is only valid for opensource.apple.com, not www.opensource.apple.com: www.opensource.apple.com uses an invalid security certificate. The certificate is only valid for opensource.apple.com (Error code: ssl_error_bad_cert_domain) You can simply use the former.


11

Those messages get a D- for technical content and accuracy. The most likely explanation is that these packets arrived late and failed the ESTABLISHED,RELATED check because the connection was already closed. Somewhat less likely is that they actually had the CONNECT flag set in the TCP header, and your firewall is either dropping all incoming connections or ...


7

No, stripping <script> tags is useless because you could still execute a javascript payload like this: <input onmouseover=prompt(document.cookie)> And bypassing the filter should also be quite easy, imagine what would happen if a payload like this sent: <scr<script>ipt> As far as what type of software they are using, well ...


5

Yes, it is absolutely safe (in Google Chrome) to open an untrusted website in view-source mode. The key point to note here is that you should "open" the page in view-source mode, meaning you should not allow any rendering to happen by normally loading the webpage first and then viewing the source. An example in Google Chrome would be ...


5

The server sends the entire certificate chain, up to and possibly including the root certificate, all at once as part of the Server Certificate TLS handshake message: certificate_list This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one ...


5

In simple terms: Your browser starts to connect to an HTTPS website, asking to use a strong cipher. The attacker intercepts this request and replaces it with one asking to use weak "export-grade" encryption. The server gets this modified request and responds to your browser with an export-grade encryption key. Your browser doesn't notice the key it got is ...


4

That is the correct behavior. In the case of client-side JavaScript, it is by design that the script source is sent to the client to be executed. So, the fact that you can manually browse to the URL for the script file is irrelevant. It gives you no more access than the application intends for you to have. A source-code disclosure vulnerability is when ...


4

The streaming server needs to know where to send the video to, thus it is aware of your IP address. Using this IP address, your estimated position can be requested from a so-called geolocation database (which connects networks to locations). This usually is not accurate to street or house level, but most of the time at least resolves the city and country ...


3

This may be to avoid the use of this header to cause a denial of service attack. Imagine an insecure HTTP-only website. Now imagine someone able to tamper with the HTTP headers sent by this site to add an HSTS header. According to the RFC: The UA should stop trying to access the site through HTTP, and try to use HTTPS only instead. If the UA is unable to ...


2

Yes, all your assumptions are correct there. As you are including content from addthis.com, your client-side Origin is fully trusting this domain. If there was any compromise to addthis.com, or if addthis.com decided to change the script to do something more invasive then your site would be vulnerable. For example, addthis.com may suddenly decide they want ...


2

The statement is not untrue but IS possibly misleading. Certainly files are in fact cached while the in-private session is active, they are then cleared at the end. Of course, we all know this could leave a footprint. In-private sessions are not really meant to prevent someone from discovering a footprint but more to prevent inadvertent "bleed" between ...


2

A source code disclosure vulnerability is an involuntary disclosure of source code. Since JavaScript code runs client-side, on the browser, it's disclosure is intentional. Under this definition, only exposure of the server-side code is a source code disclosure vulnerability. The example you give actually has the GPL on it, so it's already disclosed ...


1

HPKP does not address this need. HPKP is an extension to the HTTP protocol allowing website administrators to provide specific pining information to the browser, allowing: To check that at least one of the certificate composing the authentication chain of the current HTTPS connection (depending on the platform architecture architecture, the server ...


1

I think this extension is quite simple and generally safe to use for two reasons: Firstly, on Q. When does HTTPS Everywhere protect me? When does it not protect me? section on HTTPS Everywhere website FAQ page HTTPS Everywhere depends entirely on the security features of the individual web sites that you use; it activates those security features, ...


1

I doubt that it is possible to add custom cipher suites to Chrome or Firefox and to keep these maintained with all the rapid updates. I don't know about adding ciphers to the Windows system so that they can be used by IE, but given that even Microsoft itself has serious problems in this area I doubt that you can easily add ciphers there and keep them cheaply ...


1

An old question, but adding an answer for modern times. For sensitive responses, you should set the following header: Cache-Control: no-store, must-revalidate These days, you probably don't need to worry about the HTTP 1.0 Expires header. Pragma is only for requests, not responses. To refresh the page just after session timeout (so that the login form ...


1

This is happening because as others described, the Mail/Web shield needs to be able to scan your web traffic before it is saved on your system / does any harm. Scanning encrypted SSL/TLS sockets requires that Avast can decrypt the connection. There is no other way for Avast to decrypt the connection than to generate its own certificate with a known derived ...


1

you can make it local by giving permission on extention folder in this path C:\Users\*your user*\AppData\Local\Google\Chrome\User Data\Default\Extensions rightclick->security-> select user-> deny all



Only top voted, non community-wiki answers of a minimum length are eligible