Tag Info

Hot answers tagged

31

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 ...


20

While it is currently safe on Chrome you should not base your future checks on that. Things may change anytime and I have not seen the lack of rendering as being a specifically documented feature. If you want to look at the code, it is much better to download the page via a command-line tool (curl for instance) and analyze what was loaded and saved in a ...


4

I worked on this problem for an email scanning system, and can say that the lexical properties of URLs for maliciousness are minimal, especially with the constraints you are imposing. It's true that malicious URLs often "Look random", but that's because your experience has transformed "imgur.com/gallery/lBKRZ" into "harmless image server gallery", but ...


3

"Foolproof" does not necessarily means "NSA-proof" or whatever. A foolproof security system is meant to be a system usable by non-technical users and lowering as much as possible the risk of a misconfiguration impacting the security. Browser's, for instance, involve a lot of "foolproof" security technology against phishing sites, etc.. In case of ...


3

is there some good reason from a security perspective to allow only TLS 1.0, or is it simply pure "laziness" It is in most cases just the TLS stack used. One of the most common stacks in web servers on UNIX/Linux is OpenSSL and the still widely used (and supported) versions 0.9.8 and 1.0.0 can do only TLS 1.0 and lower. TLS 1.1 and TLS 1.2 were only ...


2

No, there is absolutely no security related reason to continue to support TLS 1.0, but there are several other business concerns which can twist the arm of a system engineer into allowing it. For larger sites, they may be trying not to leave people with older browsers out in the cold. For some situations, the person publishing the website needs to assume you ...


2

When the https portion of the URL in Chrome has a red line through it, there is a problem with the security of the site you are going to. To see exactly what the problem is, you need to click on the padlock and see the detailed connection info. Detailed connection info is documented here. If you see , then you've established a secure connection with a ...


2

The cached page still contains references to the original content (images, scripts and style-sheet files, etc.) so, when you look at the default cached page, your browser will request this content to the original website, possibly along with a "referer" header telling explicitely to the website that you are currently viewing the Google cached version of ...


2

As far as Google is concerned, they only share non-personally identifiable information with their partners (publishers, advertisers or connected sites). From Google's Privacy Policy: We may share aggregated, non-personally identifiable information publicly and with our partners – like publishers, advertisers or connected sites. For example, we may ...


2

As far as I know using windows installer a per-user install (in opposition to a per-machine install) doesn't require elevation. As to why user end up with it I noticed that many downloads from Microsoft try to bundle up software. They have a web popup window with the suggested bundled crap checked by default. If you click download without unchecking these ...


1

If it only prevents page/script from reading the response from another origin, can't we just use a proxy listener like Burp or a sniffer like wireshark to capture the response before it even reaches the browser (where SOP is implemented)? These are two different types of attack. Preventing reads from another origin prevents an attacker's site ...


1

Why does the server even respond to such requests from another origin? Shouldn't they only respond when Cross-origin resource sharing (CORS) is enabled on them? For the server a CORS XHR and a cross-site request triggered by including the resource (i.e. <img src=, <script src=) or a resource accessed by a link (<a href=) all look to similar and ...


1

While the two can be used to achieve the same objective in some cases(in this case blocking flash ads) it's not intended to that, each one complement other but one can't do everything the other can. I will explain. "Click to play" helps because: by blocking Java, Flash, SilverLight, Shockwave, Vlc plugin and more you stop a lot of tracking around the web ...


1

No, they wouldn't. That would be a serious breach of privacy. Of course if you click through on a link then at that point the site can tell your IP address and the search term that you used on Google, from their own logs.


1

Such a setup can be trusted, since the payment details cannot be extracted by your hacker and the payment details can be verified securely. The thing to watch out for is that a lot of user might not bother to double-check the details on the https page, or if there are 'hidden' paramaters sent along that aren't displayed and verified explicitly.



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