Encapsulation is about drawing strong boundaries. In a web browser that might mean ensuring that your mobile code cannot be abused by other mobile code. On the server it might mean differentiation between validated data and unvalidated data, between one user's data and another's, or between data users are allowed to see and data that they are not.
localStorage and sessionStorage can expose sensitive information unwittingly.localStorage and sessionStorage maps to allow developers to persist program values. The sessionStorage map provides storage for the invoking page and lasts only for the duration of the page instance and the immediate browser session. The localStorage map, however, provides storage that is accessible over multiple page instances and multiple browser instances. This functionality allows an application to persist and utilize the same information in multiple browser tabs or windows.sessionStorage scope to the localStorage or vice versa.sessionStorage object. However, the developer also stores the information within the localStorage object.
...
try {
sessionStorage.setItem("userCCV", currentCCV);
} catch (e) {
if (e == QUOTA_EXCEEDED_ERR) {
alert('Quota exceeded.');
}
}
...
...
var retrieveObject = sessionStorage.getItem("userCCV");
try {
localStorage.setItem("userCCV",retrieveObject);
} catch (e) {
if (e == QUOTA_EXCEEDED_ERR) {
alert('Quota exceeded.');
}
...
var userCCV = localStorage.getItem("userCCV");
...
}
...
localStorage object, the CCV information is now available in other browser tabs and also on new invocations of the browser. This will by-pass the application logic for the intended workflow.MyAccountActions and a page action method pageAction(). The pageAction() method is executed when visiting the page URL, and the server does not check for anti-CSRF tokens.
<apex:page controller="MyAccountActions" action="{!pageAction}">
...
</apex:page>
public class MyAccountActions {
...
public void pageAction() {
Map<String,String> reqParams = ApexPages.currentPage().getParameters();
if (params.containsKey('id')) {
Id id = reqParams.get('id');
Account acct = [SELECT Id,Name FROM Account WHERE Id = :id];
delete acct;
}
}
...
}
<img src="http://my-org.my.salesforce.com/apex/mypage?id=YellowSubmarine" height=1 width=1/>
RequestBuilder rb = new RequestBuilder(RequestBuilder.POST, "/new_user");
body = addToPost(body, new_username);
body = addToPost(body, new_passwd);
rb.sendRequest(body, new NewAccountCallback(callback));
RequestBuilder rb = new RequestBuilder(RequestBuilder.POST, "http://www.example.com/new_user");
body = addToPost(body, "attacker";
body = addToPost(body, "haha");
rb.sendRequest(body, new NewAccountCallback(callback));
example.com visits the malicious page while they have an active session on the site, they will unwittingly create an account for the attacker. This is a CSRF attack. It is possible because the application does not have a way to determine the provenance of the request. Any request could be a legitimate action chosen by the user or a faked action set up by an attacker. The attacker does not get to see the Web page that the bogus request generates, so the attack technique is only useful for requests that alter the state of the application.
<http auto-config="true">
...
<csrf disabled="true"/>
</http>
var req = new XMLHttpRequest();
req.open("POST", "/new_user", true);
body = addToPost(body, new_username);
body = addToPost(body, new_passwd);
req.send(body);
var req = new XMLHttpRequest();
req.open("POST", "http://www.example.com/new_user", true);
body = addToPost(body, "attacker");
body = addToPost(body, "haha");
req.send(body);
example.com visits the malicious page while she has an active session on the site, she will unwittingly create an account for the attacker. This is a CSRF attack. It is possible because the application does not have a way to determine the provenance of the request. Any request could be a legitimate action chosen by the user or a faked action set up by an attacker. The attacker does not get to see the Web page that the bogus request generates, so the attack technique is only useful for requests that alter the state of the application.
<form method="POST" action="/new_user" >
Name of new user: <input type="text" name="username">
Password for new user: <input type="password" name="user_passwd">
<input type="submit" name="action" value="Create User">
</form>
<form method="POST" action="http://www.example.com/new_user">
<input type="hidden" name="username" value="hacker">
<input type="hidden" name="user_passwd" value="hacked">
</form>
<script>
document.usr_form.submit();
</script>
example.com visits the malicious page while she has an active session on the site, she will unwittingly create an account for the attacker. This is a CSRF attack. It is possible because the application does not have a way to determine the provenance of the request. Any request could be a legitimate action chosen by the user or a faked action set up by an attacker. The attacker does not get to see the Web page that the bogus request generates, so the attack technique is only useful for requests that alter the state of the application.buyItem controller method.
+ nocsrf
POST /buyItem controllers.ShopController.buyItem
shop.com, she will unwittingly buy items for the attacker. This is a CSRF attack. It is possible because the application does not have a way to determine the provenance of the request. Any request could be a legitimate action chosen by the user or a faked action set up by an attacker. The attacker does not get to see the Web page that the bogus request generates, so the attack technique is only useful for requests that alter the state of the application.
<form method="POST" action="/new_user" >
Name of new user: <input type="text" name="username">
Password for new user: <input type="password" name="user_passwd">
<input type="submit" name="action" value="Create User">
</form>
<form method="POST" action="http://www.example.com/new_user">
<input type="hidden" name="username" value="hacker">
<input type="hidden" name="user_passwd" value="hacked">
</form>
<script>
document.usr_form.submit();
</script>
example.com visits the malicious page while she has an active session on the site, she will unwittingly create an account for the attacker. This is a CSRF attack. It is possible because the application does not have a way to determine the provenance of the request. Any request could be a legitimate action chosen by the user or a faked action set up by an attacker. The attacker does not get to see the Web page that the bogus request generates, so the attack technique is only useful for requests that alter the state of the application.X-Download-Options header being set to noopen, allows downloaded HTML pages to run in the security context of the site serving them.
var express = require('express');
var app = express();
var helmet = require('helmet');
app.use(helmet({
ieNoOpen: false
}));
...
Origin header, it will allow any malicious site to impersonate the user and establish a bidirectional WebSocket connection without the user even noticing.Origin header, it will allow any malicious site to impersonate the user and establish a bidirectional WebSocket connection without the user even noticing.exclude deny list. This is hard to maintain and error prone. If developers add new fields to the form or Model that backs up the form and forget to update the exclude filter, they may be exposing sensitive fields to attackers. Attackers will be able to submit and bind malicious data to any non-excluded field.User attributes but checks a deny list for the user id:
from myapp.models import User
...
class UserForm(ModelForm):
class Meta:
model = User
exclude = ['id']
...
User model was updated with a new role attribute and the associated UserForm was not updated, the role attribute would be exposed in the form.
...
myWebView.loadUrl("file:///android_asset/www/index.html");
...
Example 1, the Android WebView renderer treats everything loaded with loadUrl() with a URL starting with "file://" as being in the same origin.
<script src="http://www.example.com/js/fancyWidget.js"></script>
Example 2, an insecure protocol is being used that could permit the resulting script to be modified by a malicious actor. Alternatively, other attacks could be performed to re-route the machine to an attacker's site.file://).UIWebView.loadRequest(_:) method to load a local file:
...
NSURL *url = [[NSBundle mainBundle] URLForResource: filename withExtension:extension];
[webView loadRequest:[[NSURLRequest alloc] initWithURL:url]];
...
Example 1, the WebView engine treats everything loaded with UIWebView.loadRequest(_:) with a URL starting with file:// as being in the privileged local file origin.file:// URL, the Same Origin Policy will allow the scripts in this file to access any other file from the same origin, which may let an attacker access any local files containing sensitive information.file://).UIWebView.loadRequest(_:) method to load a local file:
...
let url = Bundle.main.url(forResource: filename, withExtension: extension)
self.webView!.load(URLRequest(url:url!))
...
Example 1, the WebView engine treats everything loaded with UIWebView.loadRequest(_:) with a URL starting with file:// as being in the privileged local file origin.file:// URL, the Same Origin Policy will allow the scripts in this file to access any other file from the same origin, which may let an attacker access any local files containing sensitive information.