Submitting a Javascript form without plaintext password - javascript

I have a username and password stored in a db with 2 way encryption. I would like to use these to log into a site with a JS form like this:
var form = document.createElement("form");
form.setAttribute("method", "post");
form.setAttribute("action", "http://www.someloginscript.com/");
var f = document.createElement("input");
f.setAttribute("type", "text");
f.setAttribute("name", "username");
f.setAttribute("value", myUser);
var f1 = document.createElement("input");
f1.setAttribute("type", "text");
f1.setAttribute("name", "password");
f1.setAttribute("value", myPass);
form.appendChild(field);
form.appendChild(f1);
document.body.appendChild(form);
form.submit();
I would like to submit the form with the password, however to do this I need to decrypt it first. If I decrypt it then the password is visible through the 'Inspect Element' functions. I obviously don't want this.
I have stumbled upon a site called www.clipperz.com which does exactly what I want but I am not sure how. Do I need to implement their open source encryption library from http://sourceforge.net/projects/clipperz/ ? Or is it all smoke and mirrors that makes it appear more secure?
thanks!
edit: I now know that there is no secure way of doing this. Is using curl a more secure way of submitting this form? This way I can keep all the handling of passwords server side?

You haven't specified it exactly, but it sounds like you're trying to use Javascript on one site to automate a login process into another site? Is that correct? It also sounds like you want to use a general login for all users, which you need to prevent the users from seeing.
I don't think this will be workable in the way you're trying to do it. The problem is that the user on the browser has complete access to the Javascript code and all the data it uses, via tools like Firebug. Using these tools, he can even go as far as modifying the code after the page has loaded.
In short, there is no way of letting Javascript handle the data without giving the user the ability to see it.
I would suggest a better approach might be something as follows:
Site 1 sends a message to Site 2, informing it that it wants to log in a user. It tells it the users IP address, the login details it wants to use and other relevant details.
Site 2 responds to Site 1 with a token code which Site 1 then sends to the user's browser.
The Javascript code on the user's browser then posts the token to Site 2 instead of a login name and password.
Site 2 recognises it as the token it just gave to Site 1, and that it has come from the IP address it was told about, and logs the user in as if it had received a normal set of login details.
This process obviously requires you to write code on both Site 1 and Site 2, so you have to have full access to both of them. If Site 2 is a third party system, then you may have to come up with something else.

Whatever information you end up sending to the third-party site, will have to be made available to the user's browser at some point - and at that point they'll be able to inspect it and get the information out.
Alternatively, they could look at the HTTP requests being made from their machine.
The point is, information on the user's machine can't be hidden from the user if it needs to be in a decrypted state on their machine at any point.

Related

How do password managers know when I've logged in successfully?

So you know how you are presented with a login screen and then, you fill it out, and then the browser loads the next page? At this point, somehow the password manager bar pops up for LastPass, 1Password, or some other extension, asking if you want to save the password. How do they know you've just logged in successfully??
Forms are sometimes submitted and other times the js intercepts the form submit and sends AJAX.
The response comes back and may set a new cookie, but sometimes the existing session cookie continues to be used (allows session fixation attacks but some implementations do that).
A new location is loaded or reloaded but sometimes the javascript reloads a portion of the document instead
But somehow these password managers DETECT that I've logged into a site successfully! How? Is it because I entered something in a password field, and then some form was submitted or some network request was sent? But how do they know it was successful?
Anyone familiar with these password managers able to give some useful info?
The reason I ask is that I want to develop an extension that detects when you've logged in and somehow tries to extract your user id from the service. It is for the purposes of sharing your user id with friends automatically, and letting them know (with your permission) what sites you are using a lot.
Any hints on techniques to extract the logged-in user's id on the service would also be helpful.
They aren't actually aware of a successful login in most cases. They are aware that a form with a password field was submitted, and the response was a 200OK. This may still be a page displaying an error message.
As for extracting user IDs, I'm pretty sure you mean profile pages or something similar. That will have to be done on a site by site basis as sites will have their own APIs and route structures.
As someone already answered this question, I will agree with him.
They aren't actually aware of a successful login in most cases. They are
aware that a form with a password field was submitted, and the response
was a 200OK. This may still be a page displaying an error message.
Since browsers watch for the request having a password field in it and the response status, But still you can fool the browsers easily. To get to know about the logged in userid you definitely need backend support / api. It depends on the authentication frameworks used in the back-end. But you can get the form fields easily, but extracting / finding userid from the form fields is a quiet difficult task, In most cases, form will be having only two fields there you can manage to get the userid. But in some cases like banking sites they will send few dummy fields fool such tools, Also many fields will be encrypted in the client itself to protect man in the middle attacks. In some cases userid is different from email, So its difficult task.
They only detect if the form was submitted, and it a code 200 (OK) was returned. They don't necessarily know if you were logged in, but this method works on most websites. They might also detect if a new page was loaded afterwards, since a failed login doesn't usually redirect the user. I have, however, had a prompt to save an incorrect password before.
They can detect your current tab. and each HTML element of that page.
May we they have list of login page case to detect keywords like
login,username,forgot password. and check all keyword to identify this is login page.
They just ready page and even they can read your password (yes) .
If you made request from that page & response will be 200ok it means your password is correct.
Whenever to request to server with username and password the server checks these two entry into their database and the server will found your data it will return response code 200 and using AJAX success call back script will catch the response code and will show successful message.
and also return some sort of information you can store into localStorage of browser or into cookie for further use.
I have created a couple of pages static HTML and form: So when form is submitted it goes to second page.
Let's test
<form action="test1.html">
<input type="text" />
<input type="password" />
<input type="submit" />
</form>
</body>
Chrome don't bothered anything happened. While firefox has given a popup to save password even when form is submitted to an error page.
So firefox only looks for a form submitted with a password field and asks for save password popup box.
If want to create an extension which can check wheather user is successfully logged-in and then you want to ask for password remember popup. For that you have to check for server response. I couldn't create a dynamic page to to proof read it with browser example.

Google Apps Script - how to login and fetch data?

Intro:
I am pretty inexperienced, but recently I have been trying to access some data from a website using Google Apps Scripts. However, to access the data, I must be logged into that website. There have actually been many posts about similar issues before, but none of them were very helpful until I came to this one: how to fetch a wordpress admin page using google apps script. The accepted answer gave a method for saving the cookies and sending them out again in the second request. I basically copied and pasted the code into my own GAS file. Since the problem in that post was logging into Wordpress, I tried that first, and it worked. I had to remove the if statement checking for the response code because 200 was being returned even when I entered the correct combo. I don't know if that was just an error in the post's code or what. In any case, I verified that the second request I made returned information as if I was logged in.
Details about specific site:
The actual website that I am trying to log onto has a some kind of weird hashing method that I haven't seen on any other login pages. When you click submit, the password changes to something really long before going to another page. The opening form tag looks like this:
<form action="/guardian/home.html" method="post" name="LoginForm" target="_top" id="LoginForm" onsubmit="doPCASLogin(this);">
As you can see, it has an "onsubmit" attribute, which I believe will just run "doPCASLogin(this);" when the form is submitted. I decided to play around with the page by just entering javascript into the address bar. What I found was that doing a command like this (after entering in my username and password):
javascript: document.forms[0].submit();
didn't work. So I dug around and found the function "doPCASLogin()" in a javascript file called "md5.js". I believe md5 is some kind of hash algorithm, but that doesn't really matter. The important part of "doPCASLogin()" is this:
function doPCASLogin(form) {
var originalpw = form.pw.value;
var b64pw = b64_md5(originalpw);
var hmac_md5pw = hex_hmac_md5(pskey, b64pw)
form.pw.value = hmac_md5pw;
form.dbpw.value = hex_hmac_md5(pskey, originalpw.toLowerCase())
if (form.ldappassword!=null) {
form.ldappassword.value = originalpw;
}
}
There is some other stuff as well, but I found that it didn't matter for my login. It is pretty obvious that this just runs the password through another function a few times using "pskey" (stored in a hidden input, different on each reload) as a key, and puts these in inputs on the original form ("dbpw" and "ldappassword" are hidden inputs, while "pw" is the visible password entry input). After it does this, it submits. I located this other "hex_hmac_md5()" function, which actually connects to a whole bunch of other functions to hash the password. Anyway, that doesn't matter, because I can just call the "hex_hmac_md5()" from the javascript I type in the address bar. This is the working code that I came up with, I just broke the line up for readability:
javascript:
document.forms['LoginForm']['account'].value="username";
document.forms['LoginForm']['pw'].value="hex_hmac_md5(pskey, b64_md5('password');)";
document.forms['LoginForm']['ldappassword'].value="password";
document.forms['LoginForm']['dbpw'].value="hex_hmac_md5(pskey, 'password')";
document.forms['LoginForm'].submit();
Wherever you see "username" or "password", this just means that I entered my username and password in those spots, but obviously I have removed them. When I discovered that this worked, I wrote a small Chrome extension that will automatically log me in when I go to the website (the login process is weird so Chrome doesn't remember my username and password). That was nice, but it wasn't my end goal.
Dilemma:
After discovering all this about the hashing, I tried just putting in all these values into the HTTP payload in my GAS file, though I was skeptical that it would work. It didn't, and I suspect that is because the values are just being read as strings and the javascript is not actually being run. This would make sense, because running the actual javascript would probably be a security issue. However, why would it work in the address bar then? Just as a side note, I am getting a 200 response code back, and it also seems that a cookie is being sent back too, though it may not be valid. When I read the actual response, it is just the login page again.
I also considered trying to replicate the entire function in my own code after seeing this: How to programmatically log into a website?, but since "pskey" is different on each reload, I think the hashing would have to be done with the new key on the second UrlFetch. So even if I did copy all of the functions into my GAS file, I don't think I could successfully log on because I would need to know the "pskey" that will be generated for a particular request BEFORE actually sending the request, which would be impossible. The only way this would work is if I could somehow maintain one page somehow and read it before sending data, but I don't know how I would do this with GAS.
EDIT: I have found another input, named "contextData", which is the same as "pskey" when the page is loaded. However, if I login once and look at the POST request made using Chrome Developers tools, I can copy all the input values, including "contextData", and I can send another request a second time. Using javascript in the address bar, it looks like this:
javascript:
document.forms['LoginForm']['account'].value="username";
document.forms['LoginForm']['pw'].value="value in field that browser sent once";
document.forms['LoginForm']['ldappassword'].value="password";
document.forms['LoginForm'['dbpw'].value="value in field that browser sent once";
document.forms['LoginForm'['contextData'].value="value in field that browser sent once";
document.forms['LoginForm'].submit();
I can sign into the website as many times as I want in this manner, no matter what "pskey" is, because I am submitting everything directly and no hashing is being done. However, this still doesn't work for me, so I'm kind of stuck. I should note that I have checked the other hidden input fields and I can still log in successfully with the javascript above even after clearing every input in the form.
QUESTIONS:
-was I correct in assuming that the code I was sending was being interpreted as a string?
-why is the new code below that I just recently wrote not working?
-for future reference, how would I use GAS to sign into a site like Google where a randomly generated string is sent in the login form, and must be sent back?
function getData() {
var loginURL = 'login page';
var dataURL = 'page with data';
var loginPayload = {
'account':'same as in previous code block',
'pw':"same as in previous code block",
'ldappassword':'same as in previous code block',
'dbpw':"same as in previous code block",
"contextData":"same as in previous code block",
};
var loginOptions = {'method':'post','payload':loginPayload,'followredirects':false};
var loginResponse = UrlFetchApp.fetch(loginURL,loginOptions);
var loginHeaders = loginResponse.getAllHeaders();
var cookie = [loginResponse.getAllHeaders()["Set-Cookie"]];
cookie[0] = cookie[0].split(";")[0];
cookie = cookie.join(";");
var dataHeaders = {'Cookie':cookie};
var dataOptions = {'method':'get','headers':dataHeaders};
var dataResponse = UrlFetchApp.fetch(dataURL,dataOptions);
Logger.log(dataResponse);
}
some kind of weird hashing method that I haven't seen on any other login pages
This login uses the well-known MD5 hashing algorithm from a base-64 encoded password (of note is that it uses the same password, but lowercased, for what seems like database access dbpw and has an option of sending the plaintext (!) version of the password for LDAP login).
know the "pskey" that will be generated for a particular request BEFORE actually sending the request, which would be impossible
pskey simply stores the key used in computing HMAC signature. There is nothing stopping you from hardcoding it, reading from disk, generating it or fetching from remote whenever and wherever you want (obviously, before the computation).
running the actual javascript would probably be a security issue
Although running untrusted JavaScript code is indeed a security issue, this is not what happened at all in your case. See next point for detailed explanation why. What you should've done, is to actually run the hashing functions (in 2020, Utilities service provides everything you need in that regard) before assigning them to loginPayload properties.
was I correct in assuming that the code I was sending was being interpreted as a string?
Everything you put in quotes (single or double) is treated as a sequence of characters. That's not how Google Apps Script works, this is how ECMAScript (on which it is based) is designed to work. In order to execute the functions "inside" the string, you need to use eval, but please never do that.
Now, in 2020 it took me some time to remember what javascript: protocol meant. This is the only reason why your code executed in the first place - you explicitly told the browser that what follows is JavaScript code to be executed. If someone sees this: please, don't use that ever again.
Google Apps Script is a server-side code and is not executed in the browser environment, therefore, even if you did use the protocol, it would have no effect because no evaluation took place.
why is the new code below that I just recently wrote not working?
Because of all the reasons explained above.
for future reference, how would I use GAS to sign into a site like Google where a randomly generated string is sent in the login form, and must be sent back?
If you are talking about the OAuth / OAuth2.0 authentication protocol, here is an officially endorsed library dedicated for exactly this purpose.

Ways to Encrypt and decrypt array in jquery

I am completly new to jquery and client side programing. I am trying to figure out a way of achiving this:
On the client side I have a hidden user id/profile id, which I wanna to encrypt, but while manipulating the hidden value, I have to decrypt and perform some operation on it.
I have a global array of arrays like below:
var users=[{"u_id":"1234", "u_name":"Test"},{"u_id":"12345", "u_name":"Test1"}];
this array is used by various other compoenets, e.g. when user mouse-over on the profile-id, it will get the details from the above array and display the result to him.
In short, I want to encrypt/decrypt all my global variables inside the script.
any plugin or ways to do will be highly appricated.
Encryption/decryption on the client side is entirely pointless. Encryption is used to hide something from somebody. For that you need a secret (password etc.) that you're not giving to that somebody.
If you want to encrypt and decrypt something on the client, the client will need the secret in order to do the encryption. Therefore, the client has everything it needs to decrypt any encrypted secret. That means any user has everything he needs to decrypt data and can in fact see the process happening (try breakpoints in your browser's Javascript debugger). Therefore, the entire exercise is by definition pointless. It may deter some very unskilled poker-arounder, but anyone with the skill to actually do something with the decrypted data can get it easily.
#deceze: Yes exactly, the example you have posted, lets say user 42, trying to update his age, basicaly user will see 42 as his profile id when he logsin, and then subsequent call he will make for changes he need to pass sessionkey/apikey along with profile id and data, so basically if you will suggest me how I can manage these sessionkey/apikey, so that user/hacker from outside can't missuse.. – Jayaram Pradhan 1 min ago
It's pretty simple:
Require users to be logged in via a regular login mechanism, typically involving a session id. This session identifies the user as securely as it's feasible to do anything securely over the web. Your security focus must be here.
Knowing who the user is, you can validate any and all of his actions. If the user requests to change the profile information of some user, check whether he's allowed to do that or not. No API key or anything needed. The server receives a request for change, the server knows who the requesting user is by the session, the server can decide to accept or reject the request.
In the concrete case of updating one's own profile, if the user is only allowed to update his profile and his profile alone: there needs to be only one action/URL, when a user POSTs data to that action, the server knows who the user is and updates that user's profile. The user doesn't need to submit a user id of the profile he wants to update, in fact he can't submit a user id, only his profile will ever get updated. There's no publicly accessible action that allows him to update anyone else's profile.
There is no 3.
i know no way to perform this on client side, you can serialize and obfuscate the data (like using base 64 encoding on json string).

Preventing bot form submission

I'm trying to figure out a good way to prevent bots from submitting my form, while keeping the process simple. I've read several great ideas, but I thought about adding a confirm option when the form is submitted. The user clicks submit and a Javascript confirm prompt pops up which requires user interaction.
Would this prevent bots or could a bot figure this out too easy? Below is the code and JSFIddle to demonstrate my idea:
JSFIDDLE
$('button').click(function () {
if(Confirm()) {
alert('Form submitted');
/* perform a $.post() to php */
}
else {
alert('Form not submitted');
}
});
function Confirm() {
var _question = confirm('Are you sure about this?');
var _response = (_question) ? true : false;
return _response;
}
This is one problem that a lot of people have encountered. As user166390 points out in the comments, the bot can just submit information directly to the server, bypassing the javascript (see simple utilities like cURL and Postman). Many bots are capable of consuming and interacting with the javascript now. Hari krishnan points out the use of captcha, the most prevalent and successful of which (to my knowledge) is reCaptcha. But captchas have their problems and are discouraged by the World-Wide Web compendium, mostly for reasons of ineffectiveness and inaccessibility.
And lest we forget, an attacker can always deploy human intelligence to defeat a captcha. There are stories of attackers paying for people to crack captchas for spamming purposes without the workers realizing they're participating in illegal activities. Amazon offers a service called Mechanical Turk that tackles things like this. Amazon would strenuously object if you were to use their service for malicious purposes, and it has the downside of costing money and creating a paper trail. However, there are more erhm providers out there who would harbor no such objections.
So what can you do?
My favorite mechanism is a hidden checkbox. Make it have a label like 'Do you agree to the terms and conditions of using our services?' perhaps even with a link to some serious looking terms. But you default it to unchecked and hide it through css: position it off page, put it in a container with a zero height or zero width, position a div over top of it with a higher z-index. Roll your own mechanism here and be creative.
The secret is that no human will see the checkbox, but most bots fill forms by inspecting the page and manipulating it directly, not through actual vision. Therefore, any form that comes in with that checkbox value set allows you to know it wasn't filled by a human. This technique is called a bot trap. The rule of thumb for the type of auto-form filling bots is that if a human has to intercede to overcome an individual site, then they've lost all the money (in the form of their time) they would have made by spreading their spam advertisements.
(The previous rule of thumb assumes you're protecting a forum or comment form. If actual money or personal information is on the line, then you need more security than just one heuristic. This is still security through obscurity, it just turns out that obscurity is enough to protect you from casual, scripted attacks. Don't deceive yourself into thinking this secures your website against all attacks.)
The other half of the secret is keeping it. Do not alter the response in any way if the box is checked. Show the same confirmation, thank you, or whatever message or page afterwards. That will prevent the bot from knowing it has been rejected.
I am also a fan of the timing method. You have to implement it entirely on the server side. Track the time the page was served in a persistent way (essentially the session) and compare it against the time the form submission comes in. This prevents forgery or even letting the bot know it's being timed - if you make the served time a part of the form or javascript, then you've let them know you're on to them, inviting a more sophisticated approach.
Again though, just silently discard the request while serving the same thank you page (or introduce a delay in responding to the spam form, if you want to be vindictive - this may not keep them from overwhelming your server and it may even let them overwhelm you faster, by keeping more connections open longer. At that point, you need a hardware solution, a firewall on a load balancer setup).
There are a lot of resources out there about delaying server responses to slow down attackers, frequently in the form of brute-force password attempts. This IT Security question looks like a good starting point.
Update regarding Captcha's
I had been thinking about updating this question for a while regarding the topic of computer vision and form submission. An article surfaced recently that pointed me to this blog post by Steve Hickson, a computer vision enthusiast. Snapchat (apparently some social media platform? I've never used it, feeling older every day...) launched a new captcha-like system where you have to identify pictures (cartoons, really) which contain a ghost. Steve proved that this doesn't verify squat about the submitter, because in typical fashion, computers are better and faster at identifying this simple type of image.
It's not hard to imagine extending a similar approach to other Captcha types. I did a search and found these links interesting as well:
Is reCaptcha broken?
Practical, non-image based Captchas
If we know CAPTCHA can be beat, why are we still using them?
Is there a true alternative to using CAPTCHA images?
How a trio of Hackers brought Google's reCaptcha to its knees - extra interesting because it is about the audio Captchas.
Oh, and we'd hardly be complete without an obligatory XKCD comic.
Today I successfully stopped a continuous spamming of my form. This method might not always work of course, but it was simple and worked well for this particular case.
I did the following:
I set the action property of the form to mustusejavascript.asp which just shows a message that the submission did not work and that the visitor must have javascript enabled.
I set the form's onsubmit property to a javascript function that sets the action property of the form to the real receiving page, like receivemessage.asp
The bot in question apparently does not handle javascript so I no longer see any spam from it. And for a human (who has javascript turned on) it works without any inconvenience or extra interaction at all. If the visitor has javascript turned off, he will get a clear message about that if he makes a submission.
Your code would not prevent bot submission but its not because of how your code is. The typical bot out there will more likely do an external/automated POST request to the URL (action attribute). The typical bots aren't rendering HTML, CSS, or JavaScript. They are reading the HTML and acting upon them, so any client logic will not be executed. For example, CURLing a URL will get the markup without loading or evaluating any JavaScript. One could create a simple script that looks for <form> and then does a CURL POST to that URL with the matching keys.
With that in mind, a server-side solution to prevent bot submission is necessary. Captcha + CSRF should be suffice. (http://en.wikipedia.org/wiki/Cross-site_request_forgery)
No Realy are you still thinking that Captcha or ReCap are Safe ?
Bots nowDays are smart and can easly recognise Letters on images Using OCR Tools (Search for it to understand)
I say the best way to protect your self from auto Form submitting is adding a hidden hash generated (and stored on the Session on your server of the current Client) every time you display the form for submitting !
That's all when the Bot or any Zombie submit the form you check if it the given hash equals the session stored Hash ;)
for more info Read about CSRF !
You could simply add captcha to your form. Since captchas will be different and also in images, bots cannot decode that. This is one of the most widely used security for all wesites...
you can not achieve your goal with javascript. because a client can parse your javascript and bypass your methods. You have to do validation on server side via captchas. the main idea is that you store a secret on the server side and validate the form submitted from the client with the secret on the server side.
You could measure the registration time offered no need to fill eternity to text boxes!
I ran across a form input validation that prevented programmatic input from registering.
My initial tactic was to grab the element and set it to the Option I wanted. I triggered focus on the input fields and simulated clicks to each element to get the drop downs to show up and then set the value firing the events for changing values. but when I tried to click save the inputs where not registered as having changed.
;failed automation attempt because window doesnt register changes.
;$iUse = _IEGetObjById($nIE,"InternalUseOnly_id")
;_IEAction($iUse,"focus")
;_IEAction($iUse,"click")
;_IEFormElementOptionSelect($iUse,1,1,"byIndex")
;$iEdit = _IEGetObjById($nIE,"canEdit_id")
;_IEAction($iEdit,"focus")
;_IEAction($iEdit,"click")
;_IEFormElementOptionSelect($iEdit,1,1,"byIndex")
;$iTalent = _IEGetObjById($nIE,"TalentReleaseFile_id")
;_IEAction($iTalent,"focus")
;_IEAction($iTalent,"click")
;_IEFormElementOptionSelect($iTalent,2,1,"byIndex")
;Sleep(1000)
;_IEAction(_IETagNameGetCollection($nIE,"button",1),"click")
This caused me to to rethink how input could be entered by directly manipulating the mouse's actions to simulate more selection with mouse type behavior. Needless to say I wont have to manualy upload images 1 by 1 to update product images for companies. used windows number before letters to have my script at end of the directory and when the image upload window pops up I have to use active accessibility to get the syslistview from the window and select the 2nd element which is a picture the 1st element is a folder. or the first element in a findfirstfile return only files call. I use the name to search for the item in a database of items and then access those items and update a few attributes after upload of images,then I move the file from that folder to a another folder so it doesn't get processed again and move onto the next first file in the list and loop until script name is found at the end of the update.
Just sharing how a lowly data entry person saves time, and fights all these evil form validation checks.
Regards.
This is a very short version that hasn't failed since it was implemented on my sites 4 years ago with added variances as needed over time. This can be built up with all the variables and if else statements that you require
function spamChk() {
var ent1 = document.MyForm.Email.value
var str1 = ent1.toLowerCase();
if (str1.includes("noreply")) {
document.MyForm.reset();
}
<input type="text" name="Email" oninput="spamChk()">
I had actually come here today to find out how to redirect particular spam bot IP addresses to H E L L .. just for fun
Great ideas.
I removed re-captcha a while back converted my contactform.html to contactform.asp and added this to the top (Obviously with some code in between to full-fill a few functions like sendmail, verify form filled out completely etc.).
<%
if Request.Form("Text") = 8 then
dothis
else
send them to google.com
end if
%>
On the form i stuck a basic text field with the name text so its just looks like anything not specifying what its for at all, I then stuck some text 2 lines above in red that states enter what 2 + 6 = in the box below to submit your request.

Security for an Instapaper-like bookmarklet

I'm trying to make a bookmarklet that does something similar to what Instapaper's does. I need the bookmarklet to send the URL of the page the user is visiting and the user's token(so the server identifies the user). How can this be done? Do you recommend I send a POST request or rather by routing the URL(for eg http://example.com/USER_TOKEN/URL )?
Also, will I need to worry about the user's token being stolen? If so, how can I handle that?
will I need to worry about the user's token being stolen
Since everything you transmit over plain HTTP is basically unencrypted plain-text, yes, you need to worry about the token being stolen.
What's more important imo, is that including the user token into your bookmarklet seems rather hack-ish:
What if a machine is used by multiple users A, B and C?
Users A and B are both using your service? Separate bookmarklets?
User C is pissed off about something A did - clicking his bookmarklet on a dozen porn sites sure sounds like fun, eh?
I would suggest something along the following lines:
Submit the URL to a GET (if you care about performance much) or POST (if you care about getting CRUD right) route.
Server-Side: Check if a user session exists (via cookies, obviously).
If so, process your data, send success callback as JSONP.
If not, send failure callback as JSONP which triggers a "Please Log in" popup/overlay.
Extra points are given for the "Please log in" thingy remembering the URL the user has been trying to save so he doesn't have to re-submit after having logged in.

Categories