New answers tagged

0

You can download whatever you want, the problem is the program that you are using for download that content. For example a browser downloads and then process the content, that's the main problem. If you download a virus with curl or wget, these programs just download and don't process whatever is inside in general, browsers does. For for analysis of ...


0

It doesn't protect you against form-jacking, it protects you against someone gaining access to your account despite form-jacking. Most 2FA mechanisms utilize a native apps containing a secret to generate time-based one-time passwords (continuously replacing text messages). These TOTPs work completely offline, making form-jacking virtually impossible (which ...


9

I think Steffan Ulrich's answer is technically correct. However if the OP's question were asked by a non-savvy user, I think I would answer differently. Do all websites know which previous websites were visited? Probably not without some technical gymnastics related to testing for specific previous sites. Do some websites know which previous websites were ...


3

No not without being creatively clever Here's an example. I have a simple static webserver that logs headers. I have index.html and test.html. Here is the browser request when I manually type them in one-after-the-other: index.html: GET /index.html HTTP/1.1 Host: localhost Connection: keep-alive Pragma: no-cache Cache-Control: no-cache sec-ch-ua: " ...


12

Do sites have a simple mechanism to do this? No. Is it possible to do this? Absolutely yes. Most advertising networks use this type of functionality. Their advert scripts are running on many sites around the world, so they know where you've been and can give you advertisement based on previous visits. Google analytics is probably the worst offender in this ...


42

Do websites know which previous website I visited? There is no direct cross-site access to the browsers history. But there are ways to "probe" the history and thus detect previous access to a specific page or site. Techniques to do such cross-site detecting of the users browser history are known under the term "history sniffing". Apart ...


0

Unless a Python implementation stores its secret in an HSM, it will necessarily be less secure. Strong FIDO2 authentication solutions are superior because they are designed to make it very difficult to silently steal the secrets. You ask the key "Is this valid?" and it says "yes" or "no", with no programmatic way to retrieve the ...


1

Interesting idea. I could see how an external python script could mimic what a Yubikey does, as far as generating and storing private keys that are used to authenticate with the various web sites that you would login to. But, the challenge I see is: how would the python script insert itself in the flow between the browser and the server during ...


0

Building a CA is not a very complex operation, yet it requires quite an amount of work. There are tools around that are intended to save from from a part ot that complexity, like the excellent xca. It comes with a nice documentation, even if you have to know how x509 certificates work, but everything is nicely kept in a database. You have to design your ...


1

What we have here is a question and a pair of answers that are way out of date. At the time I would have considered the private root certificate still considerable*; but today that is no longer good advice by any means at all. Let's Encrypt TLS certificates do the job better. If it's supposed to be reached by browsers across the internet, it can use Let's ...


0

You many want to consider using the Web Crypto API, and storing a private key for the user in a CryptoKey object, which you can then store in the browser's IndexedDB storage. If you set the .extractable property to false on the CryptoKey object, then the private key can only be used for decrypting messages, signing messages, or deriving shared secrets - but ...


1

You've basically covered the reasoning's behind why you don't bother encrypting items sitting on the end users devices, they need access to the data else you wouldn't be sending it to them and any method of encrypting/decrypting would need to be accessible on the frontend to make the data readable so the encryption type and password would always be available ...


3

When viewing the page source, the browser renders the html code without interpretation, that means the scripts that are either embedded or called using the <script/> tag are not executed by the browser. Any possible risk from displaying the code source would be brought by the browser (could be a bug or vulnerability) not the malicious page itself.


Top 50 recent answers are included