Thursday, June 20, 2013

JavaScript Pass by Value or Pass by Reference

In languages like C#, Java
Pass by Value: Any modification on the parameter will not be seen by the caller.
Pass by Ref: All modifications including assigning a new object is seen by the caller.
function changeStuff(num, obj1, obj2, obj3)
{
    num = num * 10;
    obj1.item = "changed";
    obj2 = {item: "changed"};
    obj3.item = "changed";
    obj3 = {item: "something"};
    obj3.item = "something new";
}

Console:
var num = 10;
var obj1 = new Object();
obj1.item = "unchanged";
var obj2 = new Object();
obj2.item = "unchanged";
var obj3 = new Object();
obj3.item = "unchanged";
changeStuff(num, obj1, obj2, obj3);
console.log(num);
console.log(obj1.item);    
console.log(obj2.item);
console.log(obj3.item);

Output:
10
changed
unchanged
changed
Note: The above code snippet was taken from stackoverflow

In JavaScript, You can think of everything as objects even the primitive types like the parameter num above. Since, Javascript is a dynamic language you are allowed to add properties on the fly. The way you see the memory management in Javascript is a little different from their C#, Java counterparts.

All parameters are actually doing Pass by Reference. I know this is debatable. But, what needs to be clearly understood is that when you assign a new object to the function parameter then the function parameter will move pointing to the new object, leaving the caller parameter to see all the changes done by the function parameter until the point of the switch.

Please pay closer attention to the output of obj3. Is this pass by value or pass by reference? It was pass by reference until a new object was assigned. Which means the caller sees all the changes until it was assigned with a new object. All changes done post the new object assignment has been scoped only upto the function call.

obj1 case is similar to obj3, just that there was no changes made to obj1 and the first operation was to set it to a new object. Hence, it acts like a Pass by Value.

If you understood then I would be glad. Please take a bow!

If you are not or if I added to the confusion, I would refer you to continue your google search.

Monday, March 4, 2013

AWS Account - Using the Free Tier

Last few days i have been investigating a lot on AWS and I guess it was time for me to have my own account. Since, i wanted to just evaluate I did not want to spend much on this investigation, unless I see some sponsors :)
So, it was obvious that I signed up for the Free Tier account. Even the Free Tier requires you to provide Credit Card details which is a marketing strategy and will get activated for pay as you go once the trial period of 12 months is complete. What I liked the most was the Free Tier can run the entire year without costing you anything as long as you stay with one micro instance EC2. 
Some of the features are hard to understand and you may very well over look at the usage.. Ex: 5 units of write capacity, and 10 units of read capacity for Amazon DynamoDB means that you cannot be doing more than 5 writes per second. So ensure to have appropriate delays so that you are not overstepping the usage limits and get charged.

You may want to activate some Alerts (CloudWatch) to get notifications when you cross your $0.00 limit, so that you can turn off the over-utilizing features.

The first impression on the overall feature set offered by AWS was spectacular. It is just a matter of a few minutes I was able to provision my developer box (EC2), MySQL DB (RDS). 
Now that my developer environment is setup, I want to go ahead and tryout some programming.. Stay tuned to know what i have learnt..

Sunday, January 6, 2013

OAuth 2.0 Presentation



Recently, I had given a technical talk on OAuth 2.0. 

I am sharing the presentation if anyone else wants to use it.

Definitely recommend the site for a complete overview http://oauth.net/2/

This is the gist of the presentation.

What is Oauth? 
It is an Open Specification that helps to Share Secured Resources across Applications in a trusted manner.
Shared Resources could be as simple as like Facebook sharing Friends list, likes and interests OR Flickr sharing photos.

Major roles regarding OAuth: 
Resource owner: An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end- user. 
Resource server: The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.
Client: An application making protected resource requests on behalf of the resource owner and with its authorization. The term client does not imply any particular implementation characteristics (e.g. whether the application executes on a server, a desktop, or other devices). 
Authorization server: The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.
Protected resource: is a resource stored on (or provided by) the server which requires authentication in order to access it.
Access tokens: are credentials used to access protected resources. An access token is a string representing an authorization issued to the client. The string is usually opaque to the client.
Refresh tokens: are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires


State: Unique code that is recognized by the application to prevent CSRF.
Grant Type: This specifies what the current request is passing to get the access token. Typically identifies the App mode.
Token Type: In 2.0 version it is ‘Bearer’ type
Revoking access could be either through code or through the IDP provider consoles.


Exploits & Vulnerabilities of interest:
Cross-site request forgery (CSRF) - 
is an exploit in which an attacker causes the user-agent of a victim end-user to follow a malicious URI (e.g. provided to the user-agent as a misleading link, image, or redirection) to a trusting server (usually established via the presence of a valid session cookie). 
The client MUST implement CSRF protection for its redirection URI. This is typically accomplished by requiring any request sent to the redirection URI endpoint to include a value that binds the request to the user-agent's authenticated state (e.g. a hash of the session cookie used to authenticate the user-agent).
A CSRF attack against the authorization server's authorization endpoint can result in an attacker obtaining end-user authorization for a malicious client without involving or alerting the end-user.
Ex: Blogs kind of feature where users can exploit the changing of the Access Token.

Cross-linking of emails – 
Some sites uses email as an assertion. It may use the identity provider’s email assertion to link to the existing sites which could become a vulnerability if the IDP doesn’t validate the email address. Register to the site using email and password. Later login to the site using IDP which uses the same email where you may smartly try and link both these accounts.

Clickjacking – 
malicious site in which it loads the authorization server's authorization endpoint web page in a transparent iframe overlaid on top of a set of dummy buttons which are carefully constructed to be placed directly under important buttons on the authorization page. When an end-user clicks a misleading visible button, the end-user is actually clicking an invisible button on the authorization page (such as an "Authorize" button).
For most newer browsers, avoidance of iframes can be enforced by the authorization server using the (non-standard) "x-frame-options" header. This header can have two values, "deny" and "sameorigin", which will block any framing, or framing by sites with a different origin, respectively.

Invalid Certificates - 
Need to verify that the SSL/TLS certificate chain validation is done properly.

Caching - 
It is a good practice to use Authorization header in order to prevent any caching of the data in the browsers or proxies.
Note: Remember to always use HTTPS/TLS where all the requests to the Protected Resource / Auth Servers are protected from being sniffed through various tools.


References:
http://www.google.co.in/url?sa=t&rct=j&q=OAuth+2.0+Replay+attacks&source=web&cd=4&ved=0CFEQFjAD&url=http%3A%2F%2Ftrac.tools.ietf.org%2Fwg%2Foauth%2Ftrac%2Fraw-attachment%2Fwiki%2FSecurityConsiderations%2Foauth20_seccons_20101107.pdf&ei=7HwoUM2JBIrqrAeakoG4CA&usg=AFQjCNHT4kW61dLdU7KmJ8CDKr6thS-Jzw