i use jsonp to post a form to a remote script. the code is something like this:
$.ajax({
type: "get",
datatype: "jsonp",
url: 'http://other-domain.com/process_form.php?param1=x&' + $("#gs_vote_form").serialize(),
data: $("#gs_vote_form").serialize(),
success: function(data) {
alert('form submitted successfully');
}
});
The form IS submitted, but... The process_form.php completely ignores cookie data that belong to the "other-domain" (does not read or write them), which is the problem for me.
Please note, i do not care about the returned data, i only use jsonp to submit the form from one site to the other silently, without actually transferring the user to the other site.
Is there any workaround for this? Something that will make cookies work?
What browser?
Cookies on other-domain will be ‘third-party cookies’, and thus in IE subject to tighter controls, as configured in the ‘privacy’ settings tab. That means, for IE's default settings, that other-domain will be prevented from using cookies unless it sets a P3P policy. (Other browsers don't use P3P as many consider it a somewhat pointless Liar's Charter.)
'?param1=x;' + $("#gs_vote_form").serialize(),
Really, are you sure other-domain allows the use of ; as an alternative parameter separator to &? Sadly PHP does not support this unless explicitly reconfigured to do so.
Related
Security team reported following code as a Cross-site scripting.
redirect: function redirect(ajax, response, status) {
window.location = response.url;
});
They gave the sample of writing in better way
$(document).ready(function(){
$("#myDiv").on("click", "button", function(){
var eid = $("#eid").val();
$("resultsDiv").append(eid);
});
});
But How I do it for my code?
It is potential cross-site scripting on the response.url parameter, because if that contains user input and the user enters javascript: alert(1), it will be run in some browsers. Whether this is exploitable depends on the circumstances (how and with what parameters is redirect called and what browser is used).
The other code really doesn't make any sense though. :)
As for the fix, it also depends on the above. Make sure callers don't include user input, and/or in redirect() you can implement input validation (eg. response.url starts with 'http', does not contain 'javascript:', etc.)
Also note that if not cross-site scripting, it can stil be an open redirect.
I'm still a bit new to Ember. I'm using Ember 1.13 with Ember Data and the DS.RESTAdapter. For debugging purposes, as well as educational (such as getting a feel for how Ember Data works with various options such as the shouldReload* functions), I want to log every API request with mainly the URL called and optionally how it was called (eg, from a store.findAll() or store.queryRecord(), etc.). Is there a single place (my guess is somewhere in adapter:application?) where I can put a single console.log('URL called: ', url, ', from: ', callingFunction); that handles all of this?
If you use the JSONAPIAdapter or the RESTAdapter just override ajax() on the adapter to log the URI:
ajax(url, type, options) {
console.log(url);
return this._super(...arguments);
}
There is no easy way to get the caller function. Analyse the callstack, if its just for debugging purposes!
But, maybe just use the Browser log XMLHttpRequest option if its for debugging?!
If you want to know how it works, checkout the code. The adapter and the store is where you can look for knowledge.
I am making a post via Jquery ajax that looks like this:
$.ajax({
type: 'POST',
url: "/sandbox/read_demands/",
data: {
"partner_ref": "PH",
"return_field": ["summary", "details"]
},
success: [read_demands_response],
dataType: 'json'
});
I then recieve the data on the server-side with a simple Django view that only prints request.POST into a log. The data then looks like this:
{u'return_field[]': [u'summary', u'details'], u'partner_ref': [u'PH']}
As you can see, the key 'return_field' has become 'return_field[]' and the value for 'partner_ref' is now a list. What on earth is going on? Am I missing something complected obvious in the jquery post that causes my data to be malformed or is do you think this error comes from somewhere else? I am trying to rule-out different possibilities until I can find the cause of the problem.
This is jquery 1.8.2 and Django 1.4 btw.
The first one is just jQuery being jQuery. For reasons best known to themselves, the makers of jQuery believe that PHP is the only way to write server-side applications, and PHP expects fields that have more than one value to have the [] suffix - so if you don't provide one, it'll add it. You just have to use it like that in Django.
However, the second one is not an error. It's just how a Django QueryDict works: any value can have multiple items, so they'll always be represented as a list. However, request.POST['partner_ref'] will correctly give the single value. And in fact to access both values of the other key, you'll need to do request.POST.getlist('return_field[]').
Edit: as pointed out in the comments, $.ajaxSettings.traditional = true; fixes the jQuery issue.
I've been dealing with the same problem, and found this related question.
How to get an array in Django posted via Ajax
The answer recommends using
request.GET.getlist('data')
I'm working on a program dealing with cookies under the kohana's HMVC structure, and I find that Kohana has 3 ways to get/set the cookie. They are
Request::current()->cookie(), Response->cookie(), and the cookie class (Cookie::set(), get())
And PHP has a native setcookie() function and $_COOKIE to deal with cookies too.
Could anyone explain their differences and, what are the situations that they should be used respectively.
Request::cookie() prior to calling Request::execute() on the same object is used to set the cookies that will be send (or have been sent in case of the initial request) along with the rest of the request.
Request::cookie() during a Request::execute() will replace $_COOKIE.
Response::cookie() during a Request::execute() will replace setcookie().
Response::cookie() after a Request::execute() is used to get the cookies set back by the server.
The Cookie helper will sign your cookies and is used by HTTP_Header to set cookies set to the Response object in your initial Request object (see Response::send_headers() in index.php).
You probably do not want to use it yourself directly if you are trying to code HMVC safe.
I have added functionality to my admin so it preserves the URL which you tried to access before it asked you to login. So, if you go to:
/admin/foo/bar?baz
It'll redirect you to:
/admin/auth/login
After you login, before my function add-on you always went to /admin/user/profile. Right now, I save /admin/foo/bar?baz in a session variable, $_SESSION['from'].
In the login <form>, the hidden value takes the value of the session:
<input type="hidden" name="from" value="<?php echo htmlspecialchars($_SESSION['from'];)?>">
Then, after the form is submitted a redirect takes place:
header('Location: ' . $_POST['from'] );
I have seen other questions relating to XSS and htmlspecialchars and am aware it won't fix all possible XSS attempts, but would this work successfully against "low level" XSS attempts?
While there's no XSS attack here, if you're using a slightly older version of PHP, you'll open yourself up to HTTP header injection, which can be worse in some cases.
If you're fetching the URL-to-be-returned-to from the HTTP referrer, then you should be protected well enough by making sure the URL is one that you control by parsing it, then only storing the return path and query string. When performing the final redirect, you should make sure that the components of the path are properly URL encoded. You can store the return URL entirely in the session instead of punting it back out to the user to possibly manipulate during the login.