Due to the need for developers to open their applications to third-party sites for functionality, there are ways to configured the Same-Origin Policy to allow custom policies that whitelist domains. However, issues arise when web servers whitelist too many domains because the more domains that can access data on a site, the more likely an attacker can exploit the site's users. The Same-Origin Policy can be configured through a number of ways:
The demo web applications listed at the top of this page all utilize insecure Same-Origin Policy configurations that whitelist all third-party domains. The attack pages give examples of how users of such web apps can be exploited simply by tricking them into visiting a malicious link. It's also important to note that CSRF protection is implemented in the web apps because this protection is bypassed when the attacker obtains the CSRF token in a response from the server (a secure Same-Origin Policy would block this response). This is utilized by the attack pages that force the victim to buy 1000 apples.
To see the Same-Origin Policy misconfigurations in action, simply visit one of the two web applications and log in (credentials are customer:password). Feel free to explore the functionality of the web apps; you can buy apples or update your credit card. This functionality is simply to demonstrate different types of exploits (i.e., forcing a victim to buy apples or retrieving the victim's credit card). To simulate an exploit, you then visit an attack page while still logged into the web app (this would be an attacker tricking you into following the link).
Before visiting an attack page, it will be useful to open your browser's developer tools or some network traffic monitoring tool, such as Burp Suite, to view the requests and reponses. If you are logged into the CORS web app, visiting the CSRF_cors.html attack page will cause you to buy 1000 apples. You can then refresh the Main Page and see the number has increased. The CSRF_java.html and CSRFSilverlightTestPage.html attack pages execute the same attack on a user logged into the custom-policies web app (second link), but are limited by the fact that the respective plugins need to be run by the victim user. This attack works because the attack pages first make a GET request to mainpage.php which responds with the victim's CSRF token (again, a secure SOP policy would block this response). The attack page then extracts the CSRF token and uses it in a POST request to buy.php with a quantity parameter of 1000. The server validates this request because it contains the victim's CSRF token and session cookie (browsers send cookies cross-origin by default).
I wrote the Flash attack page differently simply to demonstrate a different type of attack. While logged into the custom-policies web app, if a user visits the CSRF_flash.swf attack page, a cross-domain GET request is sent to editCard.php. Since this webpage displays the user's credit card #, the response will expose this card information to the attcker. Normally, the Same-Origin Policy would block this response.