New answers tagged

2

Besides cached files that you see there can be other places where browser data can be found: System swap file Temporary files (this is not the same as cache) Data in the deleted (some files can be restored after deletion) That's why, if you have some sensitive data in cached files, caring about cache files only is not sufficient. That's why consider using ...


0

Since I am the OP, I am not currently certain how to accurately and completely answer the question "Is this a security concern"? As of this time, there are no answers to this question, but 2 commenters voiced they both consider this to be a security concern. As such, I went through the Firefox source code, and figured out how to prevent JavaScript ...


0

Nevermind. Turns out intercom allows enabling something called Identity Verification, where everytime you initialize intercom with a user id, you need to also send a user_hash, which is generated using a secret shared between you and intercom and is an HMAC created using the user_id. This acts as a password that you have created for the user to log in to ...


3

When we subjected it to Penetration Testing, a finding was filed saying that "Senstive Data such as Database Name, Storage and Version were found stored in the local IndexedDB". The people who performed your pen test should be providing you with some evidence, screenshot, full/redacted values they obtained. It is possible they just ran an ...


1

Have a look at this blog post and corresponding presentation by Pomcor. It goes through various browser side storage options including IndexedDB and what vulnerabilities apply. The short answer is IndexedDB is vulnerable to malware and physical takeover attacks. It's better than many options because cryptography is done outside the browser execution ...


3

Possibly, though not so dramatically. The real trick of billion laughs attacks is that they're exponential: increasing the number of layers of recursion increases the total size (for the classic example) by a factor of 10. That's much more impressive than usual expansion relationships, such as linear (doubling input doubles the size) or quadratic (doubling ...


0

Based on the comments following the question: You might want to consider encrypting the IMAP credentials on the client-side (in-browser, using the javascript web crypto api), using an encryption key generated client-side, then storing the encrypted credentials on the server. This way, the server stores only the encrypted credentials, not the plaintext ...


3

Yes, XSS is possible. The first injection into src is secure, as " is HTML encoded, which is a proper defense against XSS in a HTML attribute value context. The second injection however is insecure, as it takes place in a JavaScript attribute context. Here, HTML encoding is not a proper defense and XSS can be achieved by injecting ');alert('1, which ...


1

When this question was asked in 2012, we did not have the Web Crypto API, but now we do. The SubtleCrypto.generateKey() function can be used to generate symmetric keys and asymmetric key pairs on the client side, in javascript. See https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/generateKey for more info.


0

When this question was asked in 2013, we did not have the Web Crypto API, but now we do. The SubtleCrypto.generateKey() function can be used to generate RSA key pairs on the client side, in javascript. See https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/generateKey for more info.


2

Your arguments seems to be based on the assumption that the majority of tracking is done based on the browser type - which it is not. It is instead based on simple things like cookies, Etag etc but also on more complex things like Javascript based fingerprinting. Such fingerprints do not only depend on the type of browser used, but also on capabilities of ...


Top 50 recent answers are included