Tag Info

Hot answers tagged

19

At least the author wrote a rather clear page on how his encryption works. Notwithstanding, this looks like a rather old-style homemade stream cipher, which is not good news, since most of such systems have been thoroughly broken. It appears to consist of a basic LFSR subsystem (two LFSR with key-dependent polynomials; the bit about the polynomials operating ...


9

WebSockets protocol is a tricky beast to evaluate right now, as it's changing frequently. After the flaws in draft-hixie-thewebsocketprotocol-76 of the WebSockets protocol discovered by Adam Barth et al. a few months ago, Firefox disabled WebSockets implementation in about:config preferences. Since then, a new protocol version is in the works, currently up ...


8

The obvious usage is client authentication. It can be used to improve security in combination with a passphrase or smartcard, or to be a convenient replacement for entering a password. The WebID single sign on protocol is an interesting proposal in this context. The main issue with client certificates is that it is bound to the browser. So if you are on ...


8

Pros It can improve security when authenticating (in addition to a multi-factor device) If used as a "client certificate", it can make MITM attacks much more difficult The Keygen tag is implemented across most non-IE browsers, making it very easy to implement Works regardless of administrator permission. With IE Active X controls can be disabled and IE ...


8

Actually, this has nothing to do with moving CryptoCat to a browser plugin/extension. It's not even related to SSL at all. Having that in mind, Stephen's answer is somewhat misleading. I'll attempt to address that. CryptoCat is still JavaScript & HTML. Give me your full attention, assume that SSL is doing its job and you're 100% sure that you're ...


7

HTTPS is still an absolute requirement, and Matasano's main point is that JavaScript can never replace HTTPS. A MITM attack could deliver a custom JavaScript payload that could read any secrets in localstorage, and an XSS payload could also compromise this data. Matasano is wrong in regards to random number generators in JavaScript. Most browsers provide ...


6

1) How can I recommend a text field be secured (as far as validating input prior to be accepted to the html parser (which I learned runs before any of the other parsers))? See https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet for information on how to prevent cross-site scripting (XSS). You will need to do data ...


5

No, I don't know any website that is doing this. Simply, because it's a silly idea. The DOM is in the memory, and when you access it you're accessing objects stored in the memory. If a website wants to do this, it would simply store the cookie in a JavaScript variable. var Cookie = 'COOKIE_VALUE'; But there are much much better ways of creating sticky ...


5

The issues are mostly the same as for secure software development in general. Note that the most critical issue for secure software development is (1) integrating security into your software development lifecycle (so security is integrated into each step of the process: design, implementation, maintenance, ops), and (2) training of developers. It is a ...


5

Local storage is a relatively new feature available to web applications, but some kind of 'industry standards' or best practices have already appeared. OWASP HTML5 cheat sheet considering your case states that: Underlying storage mechanism may vary from one user agent to the next. In other words, any authentication your application requires can be ...


4

I think it could be used to mitigate session hijacking. A server could authenticate a client and then prior to taking input from a client the server could perform a check on the client. The spec also allows you to generate a public key and challenge. Prior to submitting important information in a form, it would be nice to be able to reauthenticate the ...


4

The problem with all of these types of things is that you can't really determine how secure they are. What we do instead is place some trust in ones that have been tested over time by a large number of experience people (@ThomasPornin has an excellent answer on this, which I will try and find a link to) - this is probably why the author has placed the ...


3

In principle, values stored in sessionStorage are restricted to the same scheme + hostname + unique port, and if the browser has a clean exit these values should be deleted at the end of the session. However, according to this post it can survive a browser restart if the user chooses to "restore the session" after a crash (which means its values also exist ...


3

The W3C security instructions for this are surprisingly accurate and complete: Authors should check the origin attribute to ensure that messages are only accepted from domains that they expect to receive messages from. Otherwise, bugs in the author's message handling code could be exploited by hostile sites. Furthermore, even after checking ...


3

I am not aware of any, but I also don't think its needed. The mobile platform is nothing new. At the end of the day a lot of the same vulnerabilities affect this platform. A lot of mobile apps are just web applications where the client side of the code is written entirely in HTML/JavaScript. That being said Mobile developers violate CWE-602 more than ...


3

There are no 'scanners' yet, but you might be able to enrich existing code scanners with new rules for the HTML5. OWASP HTML5 Security Cheatsheet is a good resource you might use to compile such rules, for example it lists insecure CORS headers configuration, but it also touches other HTML5 subjects like insecure WebSockets configuration. You can also add ...


3

@Krzysztof Kotowicz has a good answer. I concur with his recommendations. Another possibility, for web applications that really want to store sensitive information on local storage, might be to store it in encrypted form. The client-side application could encrypt and authenticate it (using a symmetric-key encryption algorithm and a message authentication ...


3

The purpose of the element is to provide a secure way to authenticate users. The tag specifies a key-pair generator field in a form. More can be found here http://www.w3schools.com/html/html5_form_elements.asp


3

Here are a couple of useful resources discussing WebSocket security - all of them pretty detailed: Delivering Security Over Native Full-duplex Web Connections - a free whitepaper from Kaazing's founder & CTO HTML5 WebSocket Security is Strong - a generic WebSocket security overview Kaazing WebSocket Gateway Security is Strong - a security post on the ...


2

It's not just Mozilla that put a ban on the WebSocket protocol. Many organizations are blocking WebSocket interaction using deep packet inspection, UTM/advanced-firewall technologies, and/or secure web gateways. It may be a hurdle to ever get it working properly. If you want a lot of information regarding the security issues with the WebSocket protocol, be ...


2

I'll attempt to answer your question. So, if I understand your question correctly, you are able to inject HTML and Javascript, but it is only accessible to yourself? If this is the case, it is still potentially problematic as there might be a case where data from GET variables, child frames, parent frames, local storage, or anywhere else which might be ...


2

I general would stay away from anything where you can't review the code and you have to do encryption online. Maybe it's not the case here, but every time in the past I've seen new encryption or steganography algorithms which were available only online, it was a honeypot collecting data on what people out there might want to encrypt/hide.


2

Yup, that's the exact definition of a HTTPOnly cookie. Of course the client can do whatever it wants to itself - so this isn't surprising. The goal is to protect the client from malicious websites (as opposed to protecting the client from itself). This segues nicely into one of the Golden Rules of programming, with extra emphasis on game development: Don't ...


2

I suggest another approach: Instead of submitting the form to the server, use an XMLHttpRequest to create the account. If server side validation fails, the form and all its content is still available. If it was successful, redirect to the target page. This requires that JavaScript is enabled, but you still can fall back to normal form submission. Access to ...


2

You will be having hard time deciding on which of the two stored values to use as the user's intended password (the one in the local storage, or the one in the input field), if none of them are empty but for some reason differ. This can potentially provide for a social engineering attack vector, where the attacker prepares a trap by opening the registration ...


2

Seems to me to be a reasonably secure approach in lieu of having user accounts and session management. HTTPS is a must but I'd also look at the following points to address your specific issues. In the response of create.php, user is given a randomly-generated string. This is not stored on the server, but its hash is. Make sure the generated string is ...


1

Essentially, the only way to achieve this sort of thing is to send Javascript and HTML to the browser. But the inherent problem is that the security of the entire system is entirely dependent upon serving HTML and Javascript to the browser. And this boils down to SSL and the Certificate Authority system. So at best, the security of any purely HTML and ...


1

Document types (or DOCTYPE) is a declarative and semantical element which is part of the W3C specification regarding markup languages documents (such as XHTML). Their presence (or non-presence) within a markup document does not influence a whatever security aspect when they are being rendered and processed by a web browser. If you are writing an XHTML 1.1 ...


1

From what I know of the WebSockets protocol whilst it allows two way message passing, at a TCP level the connection is initiated by the client and as such the most firewall configurations (e.g. those which allow standard web browsing) will allow WebSockets communication without further configuration. Indeed looking at the Wikipedia Article, this is touted ...


1

It seems that the answer lies in the updated w3 link I just found. Specifically This specification does not specify how the private key generated is to be used. It is expected that after receiving the SignedPublicKeyAndChallenge (SPKAC) structure, the server will generate a client certificate and offer it back to the user for download; this ...



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