Develop Reference

How to identify Post Data is hacked using anti-forgery token

I know how anti-forgery token in ASP.NET MVC works.But still not clear about few scenarios. One I mentioned below.
submit a post request with below information
cookie token(antiforgerytoken)
form data(first name & last name)
form input hidden token(antiforgerytoken)
Before reaching server a hacker modified form data(first name & last name) leaving token info unchanged.
In this scenario, how we can make sure the data submitted securely reached server without any modification
Actually this question is asked by an interviewer. I discussed with my colleagues and I searched in Google too. Since I couldn't find a clarity on this I thought to ask here.
I am not sure if this is a valid question.If yes,any help would be appreciated

Multiple things are mixed here. The confusion is around the purpose of different protections, so let me try and get that straight.
CSRF, and antiforgerytoken
The basic threat is the following. A victim user is logged on to the victim website victim.com. Meanwhile (say in another browser tab) he visits a malicious website malicious.com that wants to exploit CSRF in victim.com. For that, malicious.com has the user post the required parameters to victim.com to call a certain function which obviously victim user did not want to perform. This is the base case of CSRF, exploiting an existing user session, malicious.com performed something on victim.com via a victim user.
This is prevented, if for example antiforgerytoken is used, because malicious.com will not be able to send the right token to victim.com, so the request will be denied.
Note that this has nothing to do with legitimate request content.
Integrity of requests
A different problem is making sure the request is received as sent, ie. data is the same. This is usually achieved by using HTTPS, which provides message integrity and encryption (among others). So if HTTPS is used, such change of data in transit is not possible.
Of course if the attacker controls either the client or the server (more precisely, the TLS endpoint, which is not always the server), ie. anything outside the TLS channel, then the attacker can modify data. But that would mean having control over the client. For example you can do this if you run a local proxy (Fiddler, Burp, ZAP Proxy, etc.) on your client - you can then change any data in the request, that's how penetration testers work. However, an attacker not having this level of control would not be able to do this.
Without HTTPS, request (and btw also response) integrity and encryption are problems that are hard to solve. The solution is HTTPS. :)

Other websites redirecting through mine

We have a homebrewed advertising system on our website. Part of this includes code that when an ad is clicked, we first go to a intermediary page that records the click data, which then redirects them along to the desired advertiser's website.
Unfortunately, our current solution requires that a URL parameter be passed to the intermediary page that is the destination URL. Some savvy advertisers have discovered that they can use this for their own nefarious purposes and "launder" their traffic through our site. In other words, on their site, they have a link along the lines of www.oursite.com/redirect?URL=www.theirtargetsite.com, making it seem like that traffic is coming from our site.
I'm working on a solution that will only redirect to a whitelist of URLs, but my first problem is more just knowing what this is called. Finding alternative and probably better solutions is difficult when I don't even know what to call it. With so much spoofing, laundering, and hijacking going on, it's hard to find help for the right topic.
What is it called when website A redirects to website C through website B without the permission of B?

The word you're looking for is open redirect. The MITRE article on this class of vulnerability has some examples of ways that this can be mitigated, e.g:
Whitelist the URLs that you will redirect to
Displaying a warning page before redirecting (probably not viable in your situation)
Use numbers to identify the URLs to redirect to (i.e, look them up in a table) instead of putting the target in a query parameter
Use a HMAC construction to "sign" URLs to redirect to, and reject redirects that don't have a valid signature

Check an iFrame is being hosted by an allowed domain

I am developing an iframe for use on a number of our partners websites.
Is there any way I can make sure it can only be used on those websites and not by anyone else
I was intending to add a compulsory querystring to the URL for the website.
Each partner would have a different value in the quesrystring dnd use that to look up an allowed domain
However, is there anyway to know the top level domain of the site hosting the iframe?
Presumably this is not sent in the http request for the iFrame? Or is it, I couldn’t see it?
Or do you need to send the domain from javascript?
Any advice?

However, is there anyway to know the top level domain of the site hosting the iframe?
Nothing reliable.
Presumably this is not sent in the http request for the iFrame? Or is it, I couldn’t see it?
It might be sent in the referer
Or do you need to send the domain from javascript?
If you want to fetch it from the framed page, you will be blocked by the same origin policy.
If you want to sent it from the framing page, you will be putting it in the query string and you can't trust it because it can be set to whatever the person writing the framing page likes.
There is also the X-Frame-Options header (but that has limited browser support).
The most reliable solution I can think of is:
Require the origin to be specified in the query string used to load the frame
Check the referer. If it doesn't match your white-list and is not blank, redirect to a page that is blank except for a link to your site with target="_top" and some JavaScript that top.location = "your site"
Check that the origin specified in the query string is on your whitelist, if it isn't act in the same way as a rejected step 2
Output an X-Frame-Options header that limits the framing to the specified origin
That is likely to catch enough browsers to discourage the framing site from framing your site.

You can try to check referrer which normal browser will send for IFrame requests on the page.
You also can use "x-frame-options" header covered in (How to Block Iframe call and MDN ) but not every browser will respect that (on other hand it is more reliable if browser supports it).

iframe's sanbox attribute might be helpful in controlling the various security aspects in an iframe including origins
http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/

The Architecture Journal of 2007 has a nice article about this: Secure Cross-Domain Communication in the Browser
Basically what the article suggests is:
If you have page A on domain 1 with an iframe with page B on domain 2 as its source , then having an iframe on page B to page C on domain 1, would allow you to pass information across domains
I haven't tested it, but this sounds like it could work.
Another possibility is create a file with a special filename (for instance a hash of the URL of page B on domain 2) and basic extension (like .htm) and place it in the root of domain 1. Checking whether the file exists on domain 1 cannot be done by javascript however, so it should be done with server side code.

Embedded screen - security

We have a web application : C# + SQL 2k5
Different companies send us information, we parse, them, do different things, and come up with a simple list for each of our customers. The list will look the same, but will have different information based on the customer.
They should not have access to each other's data.
We would like to create a page which would be embedded on their own site. I was thinking about using something like an iFrame.
Basically customer ABC would embed on his own abc.com an iframe with a URL (we will give them the parameters needed) and his clients will see our data on his site.
The other customer, lets call him xyz, has an other website xyz.com, will do the same thing, but in the url I should make a difference between them.
I would like to know how is the best, safest way to proceed.
How should I start to build up this page that is going to be embedded.
How should I make a difference between the 2 customers? The only way to get info from them is the parameters they send me, and eventually, I could get the 'parent' of my embedded iFrame, so that might help me restrict xyz to embed using url parameter info to get data from abc. See my dilemma?
Probably a unique identifier for each customer (like a GUID?) will be needed, and they woul dnot know each other's ID ... Or is there a more secure way to do things like this?
Any help would be appreciated.
Thanks

Embed a publically visible unique id in the URL and process this to extract the client id. e.g.
<IFRAME src="http://example.com/1122334455667788aabbcc">
You could check the Request.UrlReferrer to ensure that the request see this answer
However the only safe way of doing this is to provide an authenticated API that the site uses server side to process via a services API (e.g. WCF), or at the very least an authenticated HttpWebRequest; any other way leaves your data only as secure as a publically visible unique id.

Take a look at how one of the credit card processing portals do this (eg WorldPay or Paypal). There are several ways.
At the very least you need provide each customer with a unique ID that they send you.

What can I use in Place of URL Referrer check to know where the request is coming from on my domain?

I have to implement a single signon kind of solution on my website. Let's say my website is www.myweb.com and I want to allow the users to use this site who only come from a site www.sourceweb.com.
I thought URL Referrer would do but in IE may comes null.
See here
Please suggest me some alternate solution.
Thanks,
Gaurav

If you have access to www.sourceweb.com and can modify the source then a possible solution would be:
Create a webservice on www.myweb.com.
Create a link on www.sourceweb.com
When the link is clicked call the webservice to retrieve a unique id.
Redirect the user to www.myweb.com and provide the unique id in the querystring.
On www.myweb.com confirm that the unique id is valid and remove it/mark it as used.

There are many ways to skin a cat, one way in your case would be to set a cookie on the 2nd site, using a pixel gif (1x1 pixel small picture) embedded on a page of the main site. The 2nd site then can later allow access only when the cookie is already set.
To make this secure, you have to add a token to the pixel gif URL, containing a timestamp and signed using a HMAC or something similar establishing a shared secret with the other site. Then you only set the cookie when the timestamp is recent (less than a minute ago) and properly signed.

URL_REFERER is your best bet.
Keep in mind that like most HTTP headers, it is easy to forge and does not have to be provided.

The very short answer. Don't implement this yourself.
Security solutions should not be implemented but bought. The only exception being if you actually develops security solutions for other to buy of course.
Choose one of many available SSO solutions and go with that. We use Microsofts ADFS, though not perfect it gets the job done for us with very little maintance and the only real hazle is for our applications hosted on non-windows platforms like AIX.
There so many chance of screwing things up when you try to implement your own security solutions. If you disagree than just remember than anual contests are held to break the security systems of companies such as Apple,Microsoft,Mozilla and Goggle and most of the years some one takes home the price for breaking each of them.