I am working on two domains sharing the same database table an same users. They are both hosted on the same box, but contain different data and serve two separate but similar purposes.
I have: Login process ** with **JQUERY and AJAX that works fine for both sites.
I want: Once the user is logged in one domain via the PHP function in the AJAX call, to send his information to the other domain, before the full response is sent back to jquery.
In words, set up some kind of listen file in either domain that receives the user's info once they are logged in one of the domains and logs them in the other automatically.
So, jQuery in Site X ==> AJAX / PHP , which checks info, logs the use in site X, sends info to listener.php in site Y,==> back to jQuery in site X
You can pass data fairly easily to another website using a webservice, however you probably want to place security on it to ensure people don't hack your website.
Related
I have a controller like the image below. This controller hides the relevant record in the database when the fetch request is sent. Do I need to use http post for such operations in this project that I wrote with Entity framework core? The problem with this controller is that the admin executes the javascript code fetch(https://localhost:5001/admin/deletepost?delete=url) on any page. As soon as this get query runs, the relevant record is hidden or deleted from the database. Is it safe as it is? How can I make it more secure? Thank you very much to everyone who replied.
Although this method is only accessible to the admin, will the deletion of the record as a result of the admin sending this request cause a deficit?
For several reasons, POST is more secure than GET.
GET parameters are passed through the URL. This means that the parameters are stored in the server log and browser history. When using GET, you can also easily change the data submitted to the server because it is in the address bar.
The problem when comparing the security between the two is that POST may block temporary users, but it cannot block malicious users. It is very easy to forge a POST request and should not be fully trusted.
The biggest security problem of GET is not the end user's maliciousness, but the third party sending a link to the end user.
Another point is that you must consider where to use GET and POST, because GET should only be used for operations that do not change database information, and only request or read information and POST data should be used when the data will be changed.
Some web scanners will automatically click on each link (usually a GET request) instead of in a button or form (usually a POSTS request) to avoid changing the database, but for example, if you perform a delete operation after the link, you The risk of clicking on the link may be easier with more automated tools.
I have a web page A created by a PHP script which would need to use a service only available on another page B – and for various reasons, A and B can't be merged. In this particular instance, page A is a non-WordPress page and page B is WordPress-generated. And the service in question is sending emails in a specific format which is supplied by a WP plugin.
My idea is to use page A to generate the email content and then send that content to page B which then, aided by the plugin, sends the email in the appropriate format and transfers control back to page A. This would be perfectly doable – but what I would like in addition is for page B never to be displayed. The visitor should have the impression that they are dealing only with page A all the time. Can that be done and if so, how?
I do not intend this to be a WordPress question (although maybe it is), rather more generally about using another page's script in passing without displaying that other page.
If you do have source access, it would be most reliable to use the addon directly... But if you cannot, the second easiest would be to use curl to mimic the form post on page B. This would happen server side so the user wouldn't see it happening.
To figure out what you need to send in your POST request, open your browser's developer tools and watch the network tab when you send the form manually, take the URL, and all the post data. Then you'll be able to mimic it.
You may proxy https://SITEA.com/siteB/whatever to http://SITEB.com/whatever - or the other way around... I didn't fully understand the process :P
In case you just want the siteB service call, you may also send the requests via curl or a HTTP library of your choice - which might be better as you will have to get a nonce first and stuff like that.
I'm making a google-chrome-extension for a certain website, and want the browser_action to display the number of notifications a user has received on said website.
Currently, I am using an ajax request to retrieve the HTML from the website/messages page, and then I am using jQuery to count the number of "#unread > li" elements in that HTML (each one representing a new message.)
Now, I take this number and display it on the browser_action icon.
All works perfectly, the correct amount of messages are notified, BUT the user must be logged in on the site (not my site) for it to work properly, otherwise they will think that they have no messages.
I was thinking that I could detect if the user is logged in, and if not display a red ! exclamation mark on the icon. Then, when the user clicks to show the pop-up, it asks them to log in.
However, I have no idea how to actually log the user in to the website using this method: how do I send the credentials across? Or does the website have to support a request like this?
TL;DR
How can I log a user into a website I don't own remotely?
Disclaimer: I've never done a google chrome extension, but based on the rest of your question, it sounds like it's just working with JavaScript like any other web page, so I'll go ahead and answer it.
In any case, working with cookies in JavaScript can be somewhat of a pain:
https://developer.mozilla.org/en-US/docs/Web/API/document.cookie
http://www.perlscriptsjavascripts.com/js/cookies.html
I'm assuming that your server side already works with and expects cookies, so I won't try to suggest any alternatives. That being the case, your server is what needs to validate the cookie, so, IMHO, might as well set the cookie on the server side. If the server handles it, on the JS side, you simply post the username/password to a server-side page, e.g.
$.post("/user/login",{"Username":"foo","Password":"bar"},callback);
That server-side page validates the username/password and then, if successful, generates the cookie and sends a response back to the JavaScript (e.g. {"IsSuccess":true}). Upon receiving a successful response rather than an error, you just start calling the other web services to retrieve your data assuming you are logged in and build out the page.
Assuming that your web services will return HTTP error codes that help you determine a problem with the session, if you get a 401 error code, you take the user back to the login page. If you get a 403 error code, you let the user know they can't access that data...etc., all depending on your app.
Ultimately, JavaScript doesn't know whether a user is actually logged in, so you have to rely on the server to send you information in a way that is understandable so that you can direct/prompt the user as necessary.
[Edit: 2014-11-21]
You didn't answer my other question: what do you get back? If they don't set the cookie themselves at the login, then you need to get back the session token from the response they send...if they don't send you a session ID, you're SOL. If they do send you an session token/session ID, then you need to know what to name it (e.g. PHP uses something like PHPSESSID as the cookie name, but it can be whatever the coders of that domain decided on). Beyond that, you have to be able to set the cookie for THAT domain name (3rd party cookie). This may have mixed results depending on the user's settings--if they block 3rd party cookies--however, since this is a google extension and not a website, maybe it's able to bypass that kind of restriction. I know that FireFox's developer toolbar is able to manipulate cookies for all domains, so it would be a reasonable assumption you would be able to as well.
I have a homepage. After user submits their form data, I would like to first send the data to 3rd party server (no API, they only provide web page, meaning I submit form to 3rd party our service provider process.aspx page). After get the result back, I'd like to use part of the content, render it and use on my only web page. The default behavior of form submission to the 3rd party server is after I submit the form to them, they redirect me to their progress web page. Because the form processing takes long, user sees this progress page before the final search result (result.aspx) comes back.
In order to only use 3rd party final search result page without being redirected, I tried following ways, but none of them worked out due to different reasons.
on client side, I used hidden iframe, but due to iframe security constraint, containing page (my home page) cannot use javascript to detect when the iframe page finish loaded with final result page, as domain is not the same (cross domain communication is not allowed using iframe)
I send the form data to our server, using curl to submit form to 3rd party web server from our server. The problem is the result curl returned is the progress page, while curl cannot execute javascript as browser (progress page has javascript), I couldn't exec the progress page to get final price page.
using Ajax on client side, same problem, cross domain communication is not allowed for "Access-Control-Not-Allowed" as the request page and home page are not from same origin.
(not efficient, but an option) using a browserless tool like htmlunit on server, so I could get final price page using a java program. But the problem is I are not allowed to run java program on my web server (provided by web service provider).
Is it possible to achieve what I'd like to do at all? Desperate now...Any suggestions?
This flickr blog post discusses the thought behind their latest improvements to the people selector autocomplete.
One problem they had to overcome was how to parse and otherwise handle so much data (i.e., all your contacts) client-side. They tried getting XML and JSON via AJAX, but found it too slow. They then had this to say about loading the data via a dynamically generated script tag (with callback function):
JSON and Dynamic Script Tags: Fast but Insecure
Working with the theory that large
string manipulation was the problem
with the last approach, we switched
from using Ajax to instead fetching
the data using a dynamically generated
script tag. This means that the
contact data was never treated as
string, and was instead executed as
soon as it was downloaded, just like
any other JavaScript file. The
difference in performance was
shocking: 89ms to parse 10,000
contacts (a reduction of 3 orders of
magnitude), while the smallest case of
172 contacts only took 6ms. The parse
time per contact actually decreased
the larger the list became. This
approach looked perfect, except for
one thing: in order for this JSON to
be executed, we had to wrap it in a
callback method. Since it’s executable
code, any website in the world could
use the same approach to download a
Flickr member’s contact list. This was
a deal breaker. (emphasis mine)
Could someone please go into the exact security risk here (perhaps with a sample exploit)? How is loading a given file via the "src" attribute in a script tag different from loading that file via an AJAX call?
This is a good question and this exact sort of exploit was once used to steal contact lists from gmail.
Whenever a browser fetches data from a domain, it send across any cookie data that the site has set. This cookie data can then used to authenticate the user, and fetch any specific user data.
For example, when you load a new stackoverflow.com page, your browser sends your cookie data to stackoverflow.com. Stackoverflow uses that data to determine who you are, and shows the appropriate data for you.
The same is true for anything else that you load from a domain, including CSS and Javascript files.
The security vulnerability that Flickr faced was that any website could embed this javascript file hosted on Flickr's servers. Your Flickr cookie data would then be sent over as part of the request (since the javascript was hosted on flickr.com), and Flickr would generate a javascript document containing the sensitive data. The malicious site would then be able to get access to the data that was loaded.
Here is the exploit that was used to steal google contacts, which may make it more clear than my explanation above:
http://blogs.zdnet.com/Google/?p=434
If I was to put an HTML page on my website like this:
<script src="http://www.flickr.com/contacts.js"></script>
<script> // send the contact data to my server with AJAX </script>
Assuming contacts.js uses the session to know which contacts to send, I would now have a copy of your contacts.
However if the contacts are sent via JSON, I can't request them from my HTML page, because it would be a cross-domain AJAX request, which isn't allowed. I can't request the page from my server either, because I wouldn't have your session ID.
In plain english:
Unauthorised computer code (Javascript) running on people's computers is not allowed to get data from anywhere but the site on which it runs - browsers are obliged to enforce this rule.
There is no corresponding restriction on where code can be sourced from, so if you embed data in code any website the user visits can employ the user's credentials to obtain the user's data.