Skip to content

Instantly share code, notes, and snippets.

@subudeepak
Last active December 4, 2024 13:36

Revisions

  1. subudeepak revised this gist May 19, 2014. 1 changed file with 2 additions and 0 deletions.
    2 changes: 2 additions & 0 deletions WebSockets.md
    Original file line number Diff line number Diff line change
    @@ -90,6 +90,8 @@ It is as if we spent time to develop the perfect weapon and gave it to everyone

    Why we could not enforce the Same-origin policy on WebSockets when CORS is strictly made to follow the rules, I would never understand. It is like having normal border crossing and a teleporter. Every one using normal border crossing is checked thoroughly and anyone using the teleporter can feel free to come from any country. Then you make the teleporter available to every country. Grand idea ! No that is not enough. Make the teleporter so perfect that no one can disable it. We are truly geniuses !

    This vulnerability can hence be called `Cross-Site WebSockets Scripting` since this is a variation of XSS that is made more potent by WebSockets.

    # WebSockets - Help me from this nightmare please
    For now there is just a limited number of things a developer may do. The first and foremost of them all is to use your `Content-Security-Policy` header. Change it to reflect the following.
    ```
  2. subudeepak revised this gist Apr 24, 2014. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion WebSockets.md
    Original file line number Diff line number Diff line change
    @@ -95,7 +95,7 @@ For now there is just a limited number of things a developer may do. The first a
    ```
    Content-Security-Policy : connect-src 'self'
    ```
    The above prevents webSockets requests from any place but the current server. It also prevents CORS and EventSource requests. It is painful that this is only way available currently to disable this functionality. If you need to add other resources to CSP connect-src for CORS to be successful (note CORS needs one more header from the server side called `Access-Control-Allow-Origin`). If you need to add CORS support for a website, you will automatically authorize websocket requests as well. So be wart of it.
    The above prevents webSockets requests from any place but the current server. It also prevents CORS and EventSource requests. It is painful that this is only way available currently to disable this functionality. If you need to add other resources to CSP connect-src for CORS to be successful (note CORS needs one more header from the server side called `Access-Control-Allow-Origin`). If you need to add CORS support for a website, you will automatically authorize websocket requests as well. So be wary of it.

    Even if you just use a pure html website, add this using the meta tag as follows and you should be good to go.
    ```html
  3. subudeepak revised this gist Apr 24, 2014. 1 changed file with 4 additions and 4 deletions.
    8 changes: 4 additions & 4 deletions WebSockets.md
    Original file line number Diff line number Diff line change
    @@ -4,7 +4,7 @@ WebSockets is a modern HTML5 standard which makes communication between client a
    * This meant that unless the client requested for a particular resource, the server was unable to push such a resource to the client.
    * This was detrimental since the client is then forced to check with the server at regular intervals. This meant a lot of libraries focused on optimizing asynchronous calls and identifying the response of asynchronous calls. Notably the most common approach was to create on the fly functions with different names as callback functions. This can be witnessed [here](http://jqueryui.com/autocomplete/#remote-jsonp). If you open your console log and observe the network, you would notice how many connections are being made for this task. Pinging the server is not the problem but the amount of work involved in setting up a new connection everytime is. This is however essential in the old HTML standard to ensure that the client is never directly attacked by anyone.

    Modern technologies have made it possible to sandbox the browser on a whole new scale thereby making it possible for riskier modes of access to be made. Hence a lot of newer technologies have been introduced including WebSockets. WebSockets is slightly different than the standard socket implementation. In this case the protocol is still http[s] and this makes it more versatile (it has no problems in working with http proxies). The protocol is itself symbolized by ws[s]:// and it keeps the established connection open to continuous send or receive messages. WebSockets is an important and interesting protocol whose importance cannot be understated. I think that a growing number of web developers will try to implement WebSockets into their websites and it is going to be an undeniably dominant technology in the years to come.
    Modern technologies have made it possible to sandbox the browser on a whole new scale thereby making it possible for riskier modes of access to be made. Hence a lot of newer technologies have been introduced including WebSockets. WebSockets is slightly different than the standard socket implementation. In this case, the protocol is still http[s] and this makes it more versatile (it has no problems in working with http proxies). The protocol is itself symbolized by ws[s]:// and it keeps the established connection open to continuously send or receive messages. WebSockets is an important and interesting protocol whose importance cannot be understated. I think that a growing number of web developers will try to implement WebSockets into their websites and it is going to be an undeniably dominant technology in the years to come.

    > I think that a growing number of web developers will try to implement WebSockets into their websites and it is going to be an undeniably dominant technology in the years to come.
    @@ -53,15 +53,15 @@ So before we jump into the security problems of WebSockets let me show some use

    * Comments / Message notification in the website

    This is a common use case in several application where the user needs to be notified on new comments or messages. There are ui components such as the notifications api (albeit still in draft) or the user defined components. These can be updated from any JS ofcourse. The usual update sequence has been from AJAX calls. However with WebSockets, we can make that relatively simpler since the server would send any updates when needed and the number of pings needed are very low thereby reducing both the client and server footprint.
    This is a common use case in several application where the user needs to be notified on new comments or messages. There are UI components such as the notifications API (albeit still in draft) or the user defined components. These can be updated from any JS ofcourse. The usual update sequence has been from AJAX calls. However with WebSockets, we can make that relatively simpler since the server would send any updates when needed and the number of pings needed are very low thereby reducing both the client and server footprint.

    * Common editing platforms

    With the advent of HTML5, shared editing is becoming very popular. Tools from google docs, word on the web, open source projects like etherpad etc have made it a reality. Though I cannot attest to the technology behind these tools in particular, I can definitely say that WebSockets can make this possible in a native manner. Since WebSockets follows the rules of http, the authorization mechanisms and sessions you have in place as part of your existing application also carries forward.

    * Monitoring solutions

    In many cases we all monitor our servers, loads etc. and we use a http front end to see such activities in so-called real-time. The truth is this is not as real-time as we presume since the cost to establish a secure tunnel is significant. WebSockets significantly reduce such latency for any real-time monitoring.
    In many cases we all monitor our servers, loads etc. and we use a http front end to see such activities in so-called real-time. The truth is that this is not as real-time as we presume since the cost to establish a secure tunnel is significant. WebSockets significantly reduce such latency for any real-time monitoring.

    # WebSockets - Security Overview
    I know all the things I have said above make it difficult to justify that the current WebSocket specification itself poses some serious risks.
    @@ -72,7 +72,7 @@ In the pursuit of securing the server, we often forget the end-user of the web-b

    Over so many years, we have been pushing for extended features in HTML5 that we have seemingly forgotten some of the design choices we made earlier. HTML5 does give us unlimited opportunities that the mere size of one article would never be able to cover. So I will restrain myself and talk only about a few things I would like to mention.

    The first and foremost of them all is the beauty of CORS. [CORS](http://en.wikipedia.org/wiki/Cross-origin_resource_sharing) is a beauty in itself since it allows us to use a proper XMLHttpRequest across origins and achieve our purpose. Ok, let me go back to layman terms. In the browser, one of the major blocks of security has been the [Same-Origin Policy](http://en.wikipedia.org/wiki/Same-origin_policy). For those who understand SOP, please skip ahead to the next paragraph. The same-origin policy prevents a request made from one page to another if their origin is different. i.e. lets say `http://yourwebsite.com` wants to ask something from `http://mywebsite.com`, the browser would block it. This block meant that developers went around and over to find all the loopholes to overcome this. The browser allowed some **resources** to be shared (including scripts, images, video objects and such) and the developers used this mercilessly. The most used of this mechanisms is the use of [JSONP](http://en.wikipedia.org/wiki/JSONP).
    The first and foremost of them all is the beauty of CORS. [CORS](http://en.wikipedia.org/wiki/Cross-origin_resource_sharing) is a beauty in itself since it allows us to use a proper XMLHttpRequest across origins and achieve our purpose. Ok, let me go back to layman terms. In the browser, one of the major blocks of security has been the [Same-Origin Policy](http://en.wikipedia.org/wiki/Same-origin_policy). For those who understand SOP, please skip ahead to the next paragraph. The same-origin policy prevents a request made from one page to another if their origin is different. i.e. lets say `http://yourwebsite.com` wants to ask something from `http://mywebsite.com`, the browser would block it. This block meant that developers went around and over to find all the loopholes to overcome this. The browser allowed some **resources** to be shared (including scripts, images, video objects and such) and the developers used this mercilessly. The most used of these mechanisms is the use of [JSONP](http://en.wikipedia.org/wiki/JSONP).

    I will write a separate article on JSONP but know that it uses the script tag's source attribute to make GET requests to cross-domain servers. Over the years, developers have been educated on the ill effects of JSONP and encouraged to add specific headers so as to be careful. Today one can bypass the use of JSONP completely by using CORS. The beauty of CORS allows one to send all kinds of request (note: JSONP allows only GET) to other domains.

  4. subudeepak revised this gist Apr 10, 2014. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion WebSockets.md
    Original file line number Diff line number Diff line change
    @@ -88,7 +88,7 @@ I did mention earlier that JavaScript was getting more powerful and browsers wer

    It is as if we spent time to develop the perfect weapon and gave it to everyone to use at their discretion taking out the only armor we had.

    Why we could not enforce the Same-origin policy on WebSockets when CORS is strictly made to follow the rules, I would never understand. It is like having normal border crossing and a teleporter. Every one using normal border crossing is checked thoroughly and anyone using the teleporter can feel free to come from any country. Then you make the teleporter available to every country. Grand idea ! No that is not enough. Make the teleporter so perfect that no one can disable it. Now it is perfect !
    Why we could not enforce the Same-origin policy on WebSockets when CORS is strictly made to follow the rules, I would never understand. It is like having normal border crossing and a teleporter. Every one using normal border crossing is checked thoroughly and anyone using the teleporter can feel free to come from any country. Then you make the teleporter available to every country. Grand idea ! No that is not enough. Make the teleporter so perfect that no one can disable it. We are truly geniuses !

    # WebSockets - Help me from this nightmare please
    For now there is just a limited number of things a developer may do. The first and foremost of them all is to use your `Content-Security-Policy` header. Change it to reflect the following.
  5. subudeepak revised this gist Apr 10, 2014. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion WebSockets.md
    Original file line number Diff line number Diff line change
    @@ -88,7 +88,7 @@ I did mention earlier that JavaScript was getting more powerful and browsers wer

    It is as if we spent time to develop the perfect weapon and gave it to everyone to use at their discretion taking out the only armor we had.

    Why we could not enforce the Same-origin policy on WebSockets when CORS is strictly made to follow the rules, I would never understand. It is like having normal border crossing and a teleporter. Every one using normal border crossing is checked thoroughly and anyone using the teleporter can feel free to come from any country. Then you make the teleporter available to every country. Grand idea !
    Why we could not enforce the Same-origin policy on WebSockets when CORS is strictly made to follow the rules, I would never understand. It is like having normal border crossing and a teleporter. Every one using normal border crossing is checked thoroughly and anyone using the teleporter can feel free to come from any country. Then you make the teleporter available to every country. Grand idea ! No that is not enough. Make the teleporter so perfect that no one can disable it. Now it is perfect !

    # WebSockets - Help me from this nightmare please
    For now there is just a limited number of things a developer may do. The first and foremost of them all is to use your `Content-Security-Policy` header. Change it to reflect the following.
  6. subudeepak revised this gist Apr 10, 2014. 1 changed file with 8 additions and 0 deletions.
    8 changes: 8 additions & 0 deletions WebSockets.md
    Original file line number Diff line number Diff line change
    @@ -82,6 +82,14 @@ Now we are almost getting off topic. So let me get back to WebSockets. I needed
    _Why is this a nightmare?_ In case of WebSockets, we are left with very little choices. Once a much more unrestricted communication channel is established with the remote malicious server, there is no limitation on what can be done. The malicious server can then take its sweet time in evaluating every user action with no suspicious events making appropriate corrections and handling it accordingly. Further, if the channel established were a secure one, the limits of monitoring such a communication would increase as well. So it merely takes one malicious script to get so much access to one's site. This presents the single most damaging problem for any developer. Imagine, with all the modern events possible, one can monitor every DOM node for child changes, change any native action and goes without saying hijack the user's session and so on. It is almost impossible to disable this technology for your webpage since that is how JavaScript works.

    Imagine `http://yourwebsite.com` loads information from many websites. This may be temperature information or an avatar (such as gravatar - though I am not accusing gravatar specifically of any wrongdoing) or feeds (such as twitter feeds - again not accusing twitter specifically). You tend to trust and load these scripts. Similarly, the use of content-delivery network (CDN) makes our applications vulnerable if the CDN was breached. Scripts could also be loaded into the website using the cross-site scripting vulnerability. The attacker/affected vendor at this time, need not worry about what information is important or how exactly to exploit the document object model (DOM). The script merely needs to establish a connection and from that point, the `http://maliciouswebsite.com` can take its own sweet time to do whatever it wants. I might have given access to you to use details from `http://mywebsite.com` after checking the origin diligently at my server and also get affected in the process by sending data that will routed to `http://maliciouswebsite.com`. Of course, these could have happened even without WebSockets but WebSockets reduces the complexity to do this. This allows unlimited possibilities and the attacker can keep using the client in so many ways by posting one payload after another.

    I did mention earlier that JavaScript was getting more powerful and browsers were relaxing their limitations due to the presence of a sandbox. Imagine the power the hacker would get if a chrome app or firefox extension (which have access to even more powerful functionality) were to be affected. Note that WebSockets itself is not a problem and it is highly appreciated. The only non-logical problem seems to be the lack of enforcement of the same-origin policy.

    It is as if we spent time to develop the perfect weapon and gave it to everyone to use at their discretion taking out the only armor we had.

    Why we could not enforce the Same-origin policy on WebSockets when CORS is strictly made to follow the rules, I would never understand. It is like having normal border crossing and a teleporter. Every one using normal border crossing is checked thoroughly and anyone using the teleporter can feel free to come from any country. Then you make the teleporter available to every country. Grand idea !

    # WebSockets - Help me from this nightmare please
    For now there is just a limited number of things a developer may do. The first and foremost of them all is to use your `Content-Security-Policy` header. Change it to reflect the following.
    ```
  7. subudeepak revised this gist Apr 10, 2014. 1 changed file with 1 addition and 0 deletions.
    1 change: 1 addition & 0 deletions WebSockets.md
    Original file line number Diff line number Diff line change
    @@ -93,3 +93,4 @@ Even if you just use a pure html website, add this using the meta tag as follows
    ```html
    <meta http-equiv="Content-Security-Policy" content="connect-src 'self'">
    ```
    For more details on content-security-policy, please check [this](http://content-security-policy.com/) out.
  8. subudeepak revised this gist Apr 10, 2014. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion WebSockets.md
    Original file line number Diff line number Diff line change
    @@ -80,7 +80,7 @@ Now we are almost getting off topic. So let me get back to WebSockets. I needed

    > WebSockets is a nightmare because it does not come under the Same-origin policy.
    _Why is this a nightmare?_ In case of WebSockets, we are left with very little choices. Once a much more unrestricted communication channel is established with the remote malicious server, there is no limitation on what can be done. The malicious server can then take its sweet time in evaluating every user action with no suspicious events making appropriate corrections and handling it accordingly. Further, if the channel established were a secure one, the limits of monitoring such a communication would inrease as well. So it merely takes one malicious script to get so much access to one's site. This presents the single most damaging problem for any developer. Imagine, with all the modern events possible, one can monitor every dom node for child changes, change any native action and goes without saying hijack the user's session and so on. It is almost impossible to disable this technology for your webpage since that is how javascript works.
    _Why is this a nightmare?_ In case of WebSockets, we are left with very little choices. Once a much more unrestricted communication channel is established with the remote malicious server, there is no limitation on what can be done. The malicious server can then take its sweet time in evaluating every user action with no suspicious events making appropriate corrections and handling it accordingly. Further, if the channel established were a secure one, the limits of monitoring such a communication would increase as well. So it merely takes one malicious script to get so much access to one's site. This presents the single most damaging problem for any developer. Imagine, with all the modern events possible, one can monitor every DOM node for child changes, change any native action and goes without saying hijack the user's session and so on. It is almost impossible to disable this technology for your webpage since that is how JavaScript works.

    # WebSockets - Help me from this nightmare please
    For now there is just a limited number of things a developer may do. The first and foremost of them all is to use your `Content-Security-Policy` header. Change it to reflect the following.
  9. subudeepak revised this gist Apr 10, 2014. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion WebSockets.md
    Original file line number Diff line number Diff line change
    @@ -80,7 +80,7 @@ Now we are almost getting off topic. So let me get back to WebSockets. I needed

    > WebSockets is a nightmare because it does not come under the Same-origin policy.
    _Why is this a nightmare?_ In case of WebSockets, we are left with very little choices. Once a much more unrestricted communication channel is established with the remote malicious server, there is no limitation on what can be done. The malicious server can then take its sweet time in evaluating every user action with no suspicious events making appropriate corrections and handling it accordingly. Further, id the channel established were a secure one, the limits of monitoring such a communication would inrease as well. So it merely takes one malicious script to get so much access to one's site. This presents the single most damaging problem for any developer. Imagine, with all the modern events possible, one can monitor every dom node for child changes, change any native action and goes without saying hijack the user's session and so on. It is almost impossible to disable this technology for your webpage since that is how javascript works.
    _Why is this a nightmare?_ In case of WebSockets, we are left with very little choices. Once a much more unrestricted communication channel is established with the remote malicious server, there is no limitation on what can be done. The malicious server can then take its sweet time in evaluating every user action with no suspicious events making appropriate corrections and handling it accordingly. Further, if the channel established were a secure one, the limits of monitoring such a communication would inrease as well. So it merely takes one malicious script to get so much access to one's site. This presents the single most damaging problem for any developer. Imagine, with all the modern events possible, one can monitor every dom node for child changes, change any native action and goes without saying hijack the user's session and so on. It is almost impossible to disable this technology for your webpage since that is how javascript works.

    # WebSockets - Help me from this nightmare please
    For now there is just a limited number of things a developer may do. The first and foremost of them all is to use your `Content-Security-Policy` header. Change it to reflect the following.
  10. subudeepak revised this gist Apr 10, 2014. 1 changed file with 6 additions and 3 deletions.
    9 changes: 6 additions & 3 deletions WebSockets.md
    Original file line number Diff line number Diff line change
    @@ -52,13 +52,16 @@ document.addEventListener('DOMContentReady', function () { document.getElementBy
    So before we jump into the security problems of WebSockets let me show some use cases of WebSockets.

    * Comments / Message notification in the website
    This is a common use case in several application where the user needs to be notified on new comments or messages. There are ui components such as the notifications api (albeit still in draft) or the user defined components. These can be updated from any JS ofcourse. The usual update sequence has been from AJAX calls. However with WebSockets, we can make that relatively simpler since the server would send any updates when needed and the number of pings needed are very low thereby reducing both the client and server footprint.

    This is a common use case in several application where the user needs to be notified on new comments or messages. There are ui components such as the notifications api (albeit still in draft) or the user defined components. These can be updated from any JS ofcourse. The usual update sequence has been from AJAX calls. However with WebSockets, we can make that relatively simpler since the server would send any updates when needed and the number of pings needed are very low thereby reducing both the client and server footprint.

    * Common editing platforms
    With the advent of HTML5, shared editing is becoming very popular. Tools from google docs, word on the web, open source projects like etherpad etc have made it a reality. Though I cannot attest to the technology behind these tools in particular, I can definitely say that WebSockets can make this possible in a native manner. Since WebSockets follows the rules of http, the authorization mechanisms and sessions you have in place as part of your existing application also carries forward.

    With the advent of HTML5, shared editing is becoming very popular. Tools from google docs, word on the web, open source projects like etherpad etc have made it a reality. Though I cannot attest to the technology behind these tools in particular, I can definitely say that WebSockets can make this possible in a native manner. Since WebSockets follows the rules of http, the authorization mechanisms and sessions you have in place as part of your existing application also carries forward.

    * Monitoring solutions
    In many cases we all monitor our servers, loads etc. and we use a http front end to see such activities in so-called real-time. The truth is this is not as real-time as we presume since the cost to establish a secure tunnel is significant. WebSockets significantly reduce such latency for any real-time monitoring.

    In many cases we all monitor our servers, loads etc. and we use a http front end to see such activities in so-called real-time. The truth is this is not as real-time as we presume since the cost to establish a secure tunnel is significant. WebSockets significantly reduce such latency for any real-time monitoring.

    # WebSockets - Security Overview
    I know all the things I have said above make it difficult to justify that the current WebSocket specification itself poses some serious risks.
  11. subudeepak revised this gist Apr 10, 2014. 1 changed file with 3 additions and 6 deletions.
    9 changes: 3 additions & 6 deletions WebSockets.md
    Original file line number Diff line number Diff line change
    @@ -52,16 +52,13 @@ document.addEventListener('DOMContentReady', function () { document.getElementBy
    So before we jump into the security problems of WebSockets let me show some use cases of WebSockets.

    * Comments / Message notification in the website

    This is a common use case in several application where the user needs to be notified on new comments or messages. There are ui components such as the notifications api (albeit still in draft) or the user defined components. These can be updated from any JS ofcourse. The usual update sequence has been from AJAX calls. However with WebSockets, we can make that relatively simpler since the server would send any updates when needed and the number of pings needed are very low thereby reducing both the client and server footprint.
    This is a common use case in several application where the user needs to be notified on new comments or messages. There are ui components such as the notifications api (albeit still in draft) or the user defined components. These can be updated from any JS ofcourse. The usual update sequence has been from AJAX calls. However with WebSockets, we can make that relatively simpler since the server would send any updates when needed and the number of pings needed are very low thereby reducing both the client and server footprint.

    * Common editing platforms

    With the advent of HTML5, shared editing is becoming very popular. Tools from google docs, word on the web, open source projects like etherpad etc have made it a reality. Though I cannot attest to the technology behind these tools in particular, I can definitely say that WebSockets can make this possible in a native manner. Since WebSockets follows the rules of http, the authorization mechanisms and sessions you have in place as part of your existing application also carries forward.
    With the advent of HTML5, shared editing is becoming very popular. Tools from google docs, word on the web, open source projects like etherpad etc have made it a reality. Though I cannot attest to the technology behind these tools in particular, I can definitely say that WebSockets can make this possible in a native manner. Since WebSockets follows the rules of http, the authorization mechanisms and sessions you have in place as part of your existing application also carries forward.

    * Monitoring solutions

    In many cases we all monitor our servers, loads etc. and we use a http front end to see such activities in so-called real-time. The truth is this is not as real-time as we presume since the cost to establish a secure tunnel is significant. WebSockets significantly reduce such latency for any real-time monitoring.
    In many cases we all monitor our servers, loads etc. and we use a http front end to see such activities in so-called real-time. The truth is this is not as real-time as we presume since the cost to establish a secure tunnel is significant. WebSockets significantly reduce such latency for any real-time monitoring.

    # WebSockets - Security Overview
    I know all the things I have said above make it difficult to justify that the current WebSocket specification itself poses some serious risks.
  12. subudeepak revised this gist Apr 10, 2014. 1 changed file with 4 additions and 1 deletion.
    5 changes: 4 additions & 1 deletion WebSockets.md
    Original file line number Diff line number Diff line change
    @@ -51,13 +51,16 @@ document.addEventListener('DOMContentReady', function () { document.getElementBy

    So before we jump into the security problems of WebSockets let me show some use cases of WebSockets.

    * Comments / Message notification in the website.
    * Comments / Message notification in the website

    This is a common use case in several application where the user needs to be notified on new comments or messages. There are ui components such as the notifications api (albeit still in draft) or the user defined components. These can be updated from any JS ofcourse. The usual update sequence has been from AJAX calls. However with WebSockets, we can make that relatively simpler since the server would send any updates when needed and the number of pings needed are very low thereby reducing both the client and server footprint.

    * Common editing platforms

    With the advent of HTML5, shared editing is becoming very popular. Tools from google docs, word on the web, open source projects like etherpad etc have made it a reality. Though I cannot attest to the technology behind these tools in particular, I can definitely say that WebSockets can make this possible in a native manner. Since WebSockets follows the rules of http, the authorization mechanisms and sessions you have in place as part of your existing application also carries forward.

    * Monitoring solutions

    In many cases we all monitor our servers, loads etc. and we use a http front end to see such activities in so-called real-time. The truth is this is not as real-time as we presume since the cost to establish a secure tunnel is significant. WebSockets significantly reduce such latency for any real-time monitoring.

    # WebSockets - Security Overview
  13. subudeepak revised this gist Apr 10, 2014. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion WebSockets.md
    Original file line number Diff line number Diff line change
    @@ -2,7 +2,7 @@
    WebSockets is a modern HTML5 standard which makes communication between client and server a lot more simpler than ever. We are all familiar with the technology of [sockets](http://en.wikipedia.org/wiki/Network_socket). Sockets have been fundamental to network communication for a long time but usually the communication over the browser has been restricted. The general restrictions
    * The server used to have a permanent listener while the client (aka browser) was not designated any fixed listener for a more long term connection. Hence, every communication was restricted to the client demanding and the server responding.
    * This meant that unless the client requested for a particular resource, the server was unable to push such a resource to the client.
    * This was detrimental since the client is then forced to check with the server at regular intervals. This meant a lot of libraries focused on optimizing asynchronous calls and identifying the response of asynchronous calls. Notably the most common approach was to create on the fly functions with different names as callback functions. This can be witnessed [here](http://jqueryui.com/autocomplete/#remote-jsonp). In you open your console log and observe the network, you would notice how many connections are being made for this task. Pinging the server is not the problem but the amount of work involved in setting up a new connection everytime is. This is however essential in the old HTML standard to ensure that the client is never directly attacked by anyone.
    * This was detrimental since the client is then forced to check with the server at regular intervals. This meant a lot of libraries focused on optimizing asynchronous calls and identifying the response of asynchronous calls. Notably the most common approach was to create on the fly functions with different names as callback functions. This can be witnessed [here](http://jqueryui.com/autocomplete/#remote-jsonp). If you open your console log and observe the network, you would notice how many connections are being made for this task. Pinging the server is not the problem but the amount of work involved in setting up a new connection everytime is. This is however essential in the old HTML standard to ensure that the client is never directly attacked by anyone.

    Modern technologies have made it possible to sandbox the browser on a whole new scale thereby making it possible for riskier modes of access to be made. Hence a lot of newer technologies have been introduced including WebSockets. WebSockets is slightly different than the standard socket implementation. In this case the protocol is still http[s] and this makes it more versatile (it has no problems in working with http proxies). The protocol is itself symbolized by ws[s]:// and it keeps the established connection open to continuous send or receive messages. WebSockets is an important and interesting protocol whose importance cannot be understated. I think that a growing number of web developers will try to implement WebSockets into their websites and it is going to be an undeniably dominant technology in the years to come.

  14. subudeepak revised this gist Apr 10, 2014. 1 changed file with 11 additions and 2 deletions.
    13 changes: 11 additions & 2 deletions WebSockets.md
    Original file line number Diff line number Diff line change
    @@ -63,7 +63,7 @@ In many cases we all monitor our servers, loads etc. and we use a http front end
    # WebSockets - Security Overview
    I know all the things I have said above make it difficult to justify that the current WebSocket specification itself poses some serious risks.

    There have been some well known problems on the server side of the WebSockets and the most common solution has been to check the origin tag. The discussions on this topic have even expanded to include the forgery of such socket communication despite the existence of the origin tag by re-routing the socket channel from the server instead of relying on the browser. While these are very valid problems my views on the subject is that we are not looking at the *elephant in the room*.
    There have been some well known problems on the server side of the WebSockets and the most common solution has been to check the origin tag [CSWSH](http://www.christian-schneider.net/CrossSiteWebSocketHijacking.html). The discussions on this topic have even expanded to include the forgery of such socket communication despite the existence of the origin tag by re-routing the socket channel from the server instead of relying on the browser. While these are very valid problems my views on the subject is that we are not looking at the *elephant in the room*.

    In the pursuit of securing the server, we often forget the end-user of the web-browser. Let us look at why WebSockets are so special that they represents a breaking point in HTML5.

    @@ -77,7 +77,16 @@ Now we are almost getting off topic. So let me get back to WebSockets. I needed

    > WebSockets is a nightmare because it does not come under the Same-origin policy.
    _Why is this a nightmare?_ In case of WebSockets, we are left with very little choices. Once a much more unrestricted communication channel is established with the remote malicious server, there is no limitation on what can be done. The malicious server can then take its sweet time in evaluating every user action with no suspicious events making appropriate corrections and handling it accordingly. Further, id the channel established were a secure one, the limits of monitoring such a communication would inrease as well. So it merely takes one malicious script to get so much access to one's site. This presents the single most damaging problem for any developer. Imagine, with all the modern events possible, one can monitor every dom node for child changes, change any native action and goes without saying hijack the user's session and so on. It is almost impossible to disable this technology for your webpage since that is how javascript works.

    # WebSockets - Help me from this nightmare please
    For now there is just a limited number of things a developer may do. The first and foremost of them all is to use your `Content-Security-Policy` header. Change it to reflect the following.
    ```
    Content-Security-Policy : connect-src 'self'
    ```
    The above prevents webSockets requests from any place but the current server. It also prevents CORS and EventSource requests. It is painful that this is only way available currently to disable this functionality. If you need to add other resources to CSP connect-src for CORS to be successful (note CORS needs one more header from the server side called `Access-Control-Allow-Origin`). If you need to add CORS support for a website, you will automatically authorize websocket requests as well. So be wart of it.


    Even if you just use a pure html website, add this using the meta tag as follows and you should be good to go.
    ```html
    <meta http-equiv="Content-Security-Policy" content="connect-src 'self'">
    ```
  15. subudeepak revised this gist Apr 7, 2014. 1 changed file with 0 additions and 4 deletions.
    4 changes: 0 additions & 4 deletions Feed.md
    Original file line number Diff line number Diff line change
    @@ -1,4 +0,0 @@
    If you would like to receive a RSS feed of my markdown updates or like to view from another gist viewer, use http://subudeepak.roughdraft.io

    RSS Feed: http://subudeepak.roughdraft.io/feed.xml
    Permalink on Roughdraft.io: http://subudeepak.roughdraft.io/9897212-the-problems-and-some-security-implications-of-websockets
  16. subudeepak revised this gist Apr 7, 2014. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion Feed.md
    Original file line number Diff line number Diff line change
    @@ -1,4 +1,4 @@
    If you would like to receive a RSS feed of my markdown updates or like to view from a better viewer use http://subudeepak.roughdraft.io
    If you would like to receive a RSS feed of my markdown updates or like to view from another gist viewer, use http://subudeepak.roughdraft.io

    RSS Feed: http://subudeepak.roughdraft.io/feed.xml
    Permalink on Roughdraft.io: http://subudeepak.roughdraft.io/9897212-the-problems-and-some-security-implications-of-websockets
  17. subudeepak revised this gist Apr 7, 2014. 1 changed file with 4 additions and 0 deletions.
    4 changes: 4 additions & 0 deletions Feed.md
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,4 @@
    If you would like to receive a RSS feed of my markdown updates or like to view from a better viewer use http://subudeepak.roughdraft.io

    RSS Feed: http://subudeepak.roughdraft.io/feed.xml
    Permalink on Roughdraft.io: http://subudeepak.roughdraft.io/9897212-the-problems-and-some-security-implications-of-websockets
  18. subudeepak revised this gist Apr 7, 2014. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion WebSockets.md
    Original file line number Diff line number Diff line change
    @@ -4,7 +4,7 @@ WebSockets is a modern HTML5 standard which makes communication between client a
    * This meant that unless the client requested for a particular resource, the server was unable to push such a resource to the client.
    * This was detrimental since the client is then forced to check with the server at regular intervals. This meant a lot of libraries focused on optimizing asynchronous calls and identifying the response of asynchronous calls. Notably the most common approach was to create on the fly functions with different names as callback functions. This can be witnessed [here](http://jqueryui.com/autocomplete/#remote-jsonp). In you open your console log and observe the network, you would notice how many connections are being made for this task. Pinging the server is not the problem but the amount of work involved in setting up a new connection everytime is. This is however essential in the old HTML standard to ensure that the client is never directly attacked by anyone.

    Modern technologies have made it possible to sandbox the browser on a whole new scale thereby making it possible for riskier modes of access to be made. Hence a lot of newer technologies have been introduced including WebSockets. WebSockets is slightly different then the standard socket implementation. In this case the protocol is still http[s] and this makes it more versatile (it has no problems in working with http proxies). The protocol is itself symbolized by ws[s]:// and it keeps the established connection open to continuous send or receive messages. WebSockets is an important and interesting protocol whose importance cannot be understated. I think that a growing number of web developers will try to implement WebSockets into their websites and it is going to be an undeniably dominant technology in the years to come.
    Modern technologies have made it possible to sandbox the browser on a whole new scale thereby making it possible for riskier modes of access to be made. Hence a lot of newer technologies have been introduced including WebSockets. WebSockets is slightly different than the standard socket implementation. In this case the protocol is still http[s] and this makes it more versatile (it has no problems in working with http proxies). The protocol is itself symbolized by ws[s]:// and it keeps the established connection open to continuous send or receive messages. WebSockets is an important and interesting protocol whose importance cannot be understated. I think that a growing number of web developers will try to implement WebSockets into their websites and it is going to be an undeniably dominant technology in the years to come.

    > I think that a growing number of web developers will try to implement WebSockets into their websites and it is going to be an undeniably dominant technology in the years to come.
  19. subudeepak revised this gist Apr 7, 2014. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion WebSockets.md
    Original file line number Diff line number Diff line change
    @@ -8,7 +8,7 @@ Modern technologies have made it possible to sandbox the browser on a whole new

    > I think that a growing number of web developers will try to implement WebSockets into their websites and it is going to be an undeniably dominant technology in the years to come.
    An example implementation for WebSockers in JavaScript
    An example implementation for WebSockets in JavaScript
    ```javascript
    var wsUri = "wss://" + document.location.host + "/wsendpoint";
    try
  20. subudeepak revised this gist Apr 7, 2014. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion WebSockets.md
    Original file line number Diff line number Diff line change
    @@ -9,7 +9,7 @@ Modern technologies have made it possible to sandbox the browser on a whole new
    > I think that a growing number of web developers will try to implement WebSockets into their websites and it is going to be an undeniably dominant technology in the years to come.
    An example implementation for WebSockers in JavaScript
    ```
    ```javascript
    var wsUri = "wss://" + document.location.host + "/wsendpoint";
    try
    {
  21. subudeepak revised this gist Apr 7, 2014. 1 changed file with 39 additions and 0 deletions.
    39 changes: 39 additions & 0 deletions WebSockets.md
    Original file line number Diff line number Diff line change
    @@ -8,6 +8,45 @@ Modern technologies have made it possible to sandbox the browser on a whole new

    > I think that a growing number of web developers will try to implement WebSockets into their websites and it is going to be an undeniably dominant technology in the years to come.
    An example implementation for WebSockers in JavaScript
    ```
    var wsUri = "wss://" + document.location.host + "/wsendpoint";
    try
    {
    var websocketExample = new WebSocket(malwsUri);
    }
    catch(err)
    {
    onError(err);
    }
    websocketExample.onerror = function(evt) { onThisError(evt); };
    websocketExample.onmessage = function(evt) { onThisMessage(evt); };
    function onThisError(evt) {
    writeToThisScreen('ERROR:' + evt.data);
    }
    websocketExample.onopen = function(evt) { onThisOpen(evt); };
    function writeToThisScreen(message) {
    var output = document.getElementById("output");
    output.innerHTML += '<div><p>'+message+'</p></div>';
    }
    function onThisOpen() {
    writeToThisScreen("Connected to " + malwsUri);
    websocketExample.send('hello');
    }
    function onThisMessage(evt) {
    writeToThisScreen("Received from server: " + evt.data);
    }
    function closeThisConnection()
    {
    websocketExample.close();
    }
    function sendThisMessage()
    {
    websocketExample.send(document.getElementById('message').value);
    }
    document.addEventListener('DOMContentReady', function () { document.getElementById('sendMsg').addEventListener('click', websocketExample.send(document.getElementById('message').value)); });
    ```
    # WebSockets - Some interesting projects

    So before we jump into the security problems of WebSockets let me show some use cases of WebSockets.
  22. subudeepak revised this gist Apr 7, 2014. 1 changed file with 1 addition and 0 deletions.
    1 change: 1 addition & 0 deletions WebSockets.md
    Original file line number Diff line number Diff line change
    @@ -20,6 +20,7 @@ With the advent of HTML5, shared editing is becoming very popular. Tools from go

    * Monitoring solutions
    In many cases we all monitor our servers, loads etc. and we use a http front end to see such activities in so-called real-time. The truth is this is not as real-time as we presume since the cost to establish a secure tunnel is significant. WebSockets significantly reduce such latency for any real-time monitoring.

    # WebSockets - Security Overview
    I know all the things I have said above make it difficult to justify that the current WebSocket specification itself poses some serious risks.

  23. subudeepak revised this gist Apr 7, 2014. 1 changed file with 20 additions and 3 deletions.
    23 changes: 20 additions & 3 deletions WebSockets.md
    Original file line number Diff line number Diff line change
    @@ -4,20 +4,37 @@ WebSockets is a modern HTML5 standard which makes communication between client a
    * This meant that unless the client requested for a particular resource, the server was unable to push such a resource to the client.
    * This was detrimental since the client is then forced to check with the server at regular intervals. This meant a lot of libraries focused on optimizing asynchronous calls and identifying the response of asynchronous calls. Notably the most common approach was to create on the fly functions with different names as callback functions. This can be witnessed [here](http://jqueryui.com/autocomplete/#remote-jsonp). In you open your console log and observe the network, you would notice how many connections are being made for this task. Pinging the server is not the problem but the amount of work involved in setting up a new connection everytime is. This is however essential in the old HTML standard to ensure that the client is never directly attacked by anyone.

    Modern technologies have made it possible to sandbox the browser on a whole new scale thereby making it possible for riskier modes of access to be made.
    Modern technologies have made it possible to sandbox the browser on a whole new scale thereby making it possible for riskier modes of access to be made. Hence a lot of newer technologies have been introduced including WebSockets. WebSockets is slightly different then the standard socket implementation. In this case the protocol is still http[s] and this makes it more versatile (it has no problems in working with http proxies). The protocol is itself symbolized by ws[s]:// and it keeps the established connection open to continuous send or receive messages. WebSockets is an important and interesting protocol whose importance cannot be understated. I think that a growing number of web developers will try to implement WebSockets into their websites and it is going to be an undeniably dominant technology in the years to come.

    > I think that a growing number of web developers will try to implement WebSockets into their websites and it is going to be an undeniably dominant technology in the years to come.
    # WebSockets - Some interesting projects

    So before we jump into the security problems of WebSockets let me show some use cases of WebSockets.

    * Comments / Message notification in the website.
    This is a common use case in several application where the user needs to be notified on new comments or messages. There are ui components such as the notifications api (albeit still in draft) or the user defined components. These can be updated from any JS ofcourse. The usual update sequence has been from AJAX calls. However with WebSockets, we can make that relatively simpler since the server would send any updates when needed and the number of pings needed are very low thereby reducing both the client and server footprint.

    * Common editing platforms
    With the advent of HTML5, shared editing is becoming very popular. Tools from google docs, word on the web, open source projects like etherpad etc have made it a reality. Though I cannot attest to the technology behind these tools in particular, I can definitely say that WebSockets can make this possible in a native manner. Since WebSockets follows the rules of http, the authorization mechanisms and sessions you have in place as part of your existing application also carries forward.

    * Monitoring solutions
    In many cases we all monitor our servers, loads etc. and we use a http front end to see such activities in so-called real-time. The truth is this is not as real-time as we presume since the cost to establish a secure tunnel is significant. WebSockets significantly reduce such latency for any real-time monitoring.
    # WebSockets - Security Overview
    I know all the things I have said above make it difficult to justify that the current WebSocket specification itself poses some serious risks.

    There have been some well known problems on the server side of the WebSockets and the most common solution has been to check the origin tag. The discussions on this topic have even expanded to include the forgery of such socket communication despite the existence of the origin tag by re-routing the socket channel from the server instead of relying on the browser. While these are very valid problems my views on the subject is that we are not looking at the *elephant in the room*.

    In the pursuit of securing the server, we often forget the end-user of the web-browser. Let us look at why WebSockets are so special that they represents a breaking point in HTML5.
    In the pursuit of securing the server, we often forget the end-user of the web-browser. Let us look at why WebSockets are so special that they represents a breaking point in HTML5.

    Over so many years, we have been pushing for extended features in HTML5 that we have seemingly forgotten some of the design choices we made earlier. HTML5 does give us unlimited opportunities that the mere size of one article would never be able to cover. So I will restrain myself and talk only about a few things I would like to mention.

    The first and foremost of them all is the beauty of CORS. [CORS](http://en.wikipedia.org/wiki/Cross-origin_resource_sharing) is a beauty in itself since it allows us to use a proper XMLHttpRequest across origins and achieve our purpose. Ok, let me go back to layman terms. In the browser, one of the major blocks of security has been the [Same-Origin Policy](http://en.wikipedia.org/wiki/Same-origin_policy). For those who understand SOP, please skip ahead to the next paragraph. The same-origin policy prevents a request made from one page to another if their origin is different. i.e. lets say `http://yourwebsite.com` wants to ask something from `http://mywebsite.com`, the browser would block it. This block meant that developers went around and over to find all the loopholes to overcome this. The browser allowed some **resources** to be shared (including scripts, images, video objects and such) and the developers used this mercilessly. The most used of this mechanisms is the use of [JSONP](http://en.wikipedia.org/wiki/JSONP).

    I will write a separate article on JSONP but know that it uses the script tag's source attribute to make GET requests to cross-domain servers. Over the years, developers have been educated on the ill effects of JSONP and encouraged to add specific headers so as to be careful. Today one can bypass the use of JSONP completely by using CORS. The beauty of CORS allows one to send all kinds of request (note: JSONP allows only GET) to other domains.

    Now we are almost getting off topic. So let me get back to WebSockets. I needed to provide CORS as an example because it matters significantly here. We have made a XMLHttpRequest so neat and well-balanced with proper support of a **whitelist**. In security, we always argue that a **whitelist** is better than a **blacklist** for obvious reasons.
    Now we are almost getting off topic. So let me get back to WebSockets. I needed to provide CORS as an example because it matters significantly here. We have made a XMLHttpRequest so neat and well-balanced with proper support of a **whitelist**. In security, we always argue that a **whitelist** is better than a **blacklist** for obvious reasons. WebSockets is a nightmare because it does not come under the Same-origin policy.

    > WebSockets is a nightmare because it does not come under the Same-origin policy.

  24. subudeepak revised this gist Apr 1, 2014. 1 changed file with 17 additions and 1 deletion.
    18 changes: 17 additions & 1 deletion WebSockets.md
    Original file line number Diff line number Diff line change
    @@ -7,4 +7,20 @@ WebSockets is a modern HTML5 standard which makes communication between client a
    Modern technologies have made it possible to sandbox the browser on a whole new scale thereby making it possible for riskier modes of access to be made.

    # WebSockets - Security Overview
    There have been some well known problems on the server side of the websockets and the most common solution has been to check the origin tag. The discussions on this topic have even expanded to include the forgery of such socket communication despite the existence of the origin tag by re-routing the socket channel from the server instead of relying on the browser. While these are very valid problems my views on the subject is that we are not looking at the *elephant in the room*.
    There have been some well known problems on the server side of the WebSockets and the most common solution has been to check the origin tag. The discussions on this topic have even expanded to include the forgery of such socket communication despite the existence of the origin tag by re-routing the socket channel from the server instead of relying on the browser. While these are very valid problems my views on the subject is that we are not looking at the *elephant in the room*.

    In the pursuit of securing the server, we often forget the end-user of the web-browser. Let us look at why WebSockets are so special that they represents a breaking point in HTML5.

    Over so many years, we have been pushing for extended features in HTML5 that we have seemingly forgotten some of the design choices we made earlier. HTML5 does give us unlimited opportunities that the mere size of one article would never be able to cover. So I will restrain myself and talk only about a few things I would like to mention.

    The first and foremost of them all is the beauty of CORS. [CORS](http://en.wikipedia.org/wiki/Cross-origin_resource_sharing) is a beauty in itself since it allows us to use a proper XMLHttpRequest across origins and achieve our purpose. Ok, let me go back to layman terms. In the browser, one of the major blocks of security has been the [Same-Origin Policy](http://en.wikipedia.org/wiki/Same-origin_policy). For those who understand SOP, please skip ahead to the next paragraph. The same-origin policy prevents a request made from one page to another if their origin is different. i.e. lets say `http://yourwebsite.com` wants to ask something from `http://mywebsite.com`, the browser would block it. This block meant that developers went around and over to find all the loopholes to overcome this. The browser allowed some **resources** to be shared (including scripts, images, video objects and such) and the developers used this mercilessly. The most used of this mechanisms is the use of [JSONP](http://en.wikipedia.org/wiki/JSONP).

    I will write a separate article on JSONP but know that it uses the script tag's source attribute to make GET requests to cross-domain servers. Over the years, developers have been educated on the ill effects of JSONP and encouraged to add specific headers so as to be careful. Today one can bypass the use of JSONP completely by using CORS. The beauty of CORS allows one to send all kinds of request (note: JSONP allows only GET) to other domains.

    Now we are almost getting off topic. So let me get back to WebSockets. I needed to provide CORS as an example because it matters significantly here. We have made a XMLHttpRequest so neat and well-balanced with proper support of a **whitelist**. In security, we always argue that a **whitelist** is better than a **blacklist** for obvious reasons.
    > WebSockets is a nightmare because it does not come under the Same-origin policy.

    # WebSockets - Help me from this nightmare please


  25. subudeepak revised this gist Apr 1, 2014. 1 changed file with 5 additions and 1 deletion.
    6 changes: 5 additions & 1 deletion WebSockets.md
    Original file line number Diff line number Diff line change
    @@ -1,6 +1,10 @@
    # WebSockets - An Introduction
    WebSockets is a modern HTML5 standard which makes communication between client and server a lot more simpler than ever. We are all familiar with the technology of [sockets](http://en.wikipedia.org/wiki/Network_socket). Sockets have been fundamental to network communication for a long time but usually the communication over the browser has been restricted. The general restrictions
    > The
    * The server used to have a permanent listener while the client (aka browser) was not designated any fixed listener for a more long term connection. Hence, every communication was restricted to the client demanding and the server responding.
    * This meant that unless the client requested for a particular resource, the server was unable to push such a resource to the client.
    * This was detrimental since the client is then forced to check with the server at regular intervals. This meant a lot of libraries focused on optimizing asynchronous calls and identifying the response of asynchronous calls. Notably the most common approach was to create on the fly functions with different names as callback functions. This can be witnessed [here](http://jqueryui.com/autocomplete/#remote-jsonp). In you open your console log and observe the network, you would notice how many connections are being made for this task. Pinging the server is not the problem but the amount of work involved in setting up a new connection everytime is. This is however essential in the old HTML standard to ensure that the client is never directly attacked by anyone.

    Modern technologies have made it possible to sandbox the browser on a whole new scale thereby making it possible for riskier modes of access to be made.

    # WebSockets - Security Overview
    There have been some well known problems on the server side of the websockets and the most common solution has been to check the origin tag. The discussions on this topic have even expanded to include the forgery of such socket communication despite the existence of the origin tag by re-routing the socket channel from the server instead of relying on the browser. While these are very valid problems my views on the subject is that we are not looking at the *elephant in the room*.
  26. subudeepak revised this gist Apr 1, 2014. 1 changed file with 5 additions and 1 deletion.
    6 changes: 5 additions & 1 deletion WebSockets.md
    Original file line number Diff line number Diff line change
    @@ -1,2 +1,6 @@
    # WebSockets - An Introduction
    WebSockets is a modern HTML5 standard which makes communication between client and server a lot more simpler
    WebSockets is a modern HTML5 standard which makes communication between client and server a lot more simpler than ever. We are all familiar with the technology of [sockets](http://en.wikipedia.org/wiki/Network_socket). Sockets have been fundamental to network communication for a long time but usually the communication over the browser has been restricted. The general restrictions
    > The
    # WebSockets - Security Overview
    There have been some well known problems on the server side of the websockets and the most common solution has been to check the origin tag. The discussions on this topic have even expanded to include the forgery of such socket communication despite the existence of the origin tag by re-routing the socket channel from the server instead of relying on the browser. While these are very valid problems my views on the subject is that we are not looking at the *elephant in the room*.
  27. subudeepak revised this gist Apr 1, 2014. 1 changed file with 2 additions and 2 deletions.
    4 changes: 2 additions & 2 deletions WebSockets.md
    Original file line number Diff line number Diff line change
    @@ -1,2 +1,2 @@
    #WebSockets - An Introduction
    WebSockets is a modern HTML5 standard which makes communication between client and server a lot more simpler
    # WebSockets - An Introduction
    WebSockets is a modern HTML5 standard which makes communication between client and server a lot more simpler
  28. subudeepak created this gist Mar 31, 2014.
    2 changes: 2 additions & 0 deletions WebSockets.md
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,2 @@
    #WebSockets - An Introduction
    WebSockets is a modern HTML5 standard which makes communication between client and server a lot more simpler