i am passing a secret code to the front end, from my backend. I want to store the value in my JS script, like so:
<script>
var code = '<%= code %>'
</script>
then when the user types in the code, i want to run a check to make sure it matches with the code i passed through. I'm doing this so it eliminates the struggle of going to the backend and refreshing again.
However, when i right click, and inspect element, i can actually see the code in my web browser, which is a problem. Is there a better way to do this, or a way to hide it?
The browser works for the user not the site author.
You cannot give something to the browser and expect it to keep it a secret from the user.
Do the check server-side. Live with the extra HTTP request.
There is no way to have "secret" Javascript code run in the browser. The closest thing to that would be to use a minified/uglified script, but security through obscurity is also not a valid solution.
Related
One of our clients received a social engineering warning from google. There is nothing hosted on the client's site and all I can assume is that the code is embedded in the URL. How can I stop this and make sure that the URL is not being taken advantage of?
Code below -
http://blog.essentialtech.com[.]au/events/public/v1/track/c/*W42X1Kh4VlKV7W4NDyrQ4Jwqwc0/*W34SKKS4FTw8nW7PlP8S8lBlFP0/5/f18dQhb0SfHC9dsQ84N7cW9rzHyjJqVS9MQR2B872gW3hHhb35zh-NRVnQ9Qq8Z_8m8W328bd38Xl1YFW2Mk5st5mZ50NMH5sdmJ4m23N8_dF8cJVPWRW4c2Tyb6d_m0TVHG2xy2R1bM2W2N6lzq4cj1_jW2pzD7d2MTPSyVKng6q1Wg4bjW58jf-C34RCjxW2p2f452LHP4rW5x5KNk7-XB_5N4Qzp5DMBCsfW7pKMHF2K4XMjW8tzC3F8q-1tCN1KKm4vRFkK4W5G18Kh3y9KYQN3dgtM7YrDrqW5hfJ425v5Cb1W8x-WCY3tg8kZN6p6WGsDLwCnW5BLL855GJB9nW5lW2Zn30_g8xW5kXBFn6n161-W38SQwr2Yy7gbW8Knjr38f7c2WW5rTvwF42SsX8W5nLxq_8r0-2RW30v4M38wyznpN3Gyjm6BNxmYW3gfMK48j556ZN8q1-LpjGXPKN64V3lHJRhw9VcZLWR86l4pCW8yq-Kr3rJTdsN5d_Q0Zj8tbNW480YZF3psJYWW8l-5SS6S8BxvW2RLxLy7X8G2fW5SdKBQ8s1s46W32wFFH1NsfDKSqhY367YLr102?_ud=617a5272-4c86-4d80-987a-d62228fd4f5e
This could be referring to a situation where in your code you're directly outputting the value of a query parameter or URL part in your page itself.
HubSpot has some automatic protections to prevent that kind of code injection, but there's still some best practices you should follow regardless of what CMS platform you're using.
Never trust query parameters as having only valid data. Never directly output it on the page. You can use HubL filters such as |escape and |striptags to remove potentially harmful code in the event you do need to display the value in the page.
An example of a time you might do that might be for a search results page, where you show "Search results for :"
I'm totally new to make a website with javascript AJAX. I want to provide every experience on my website with one domain(like Facebook), thus I made every page-changing method with javascript AJAX. At first, when you visit my website, you have to log in, after that it turns to the main page and you can go to several menus with clicking button which triggers page-changing method.
The problem what I faced is.. I've recently seen someone typed javascript code into the console to delete all of his(or her) photos on Tumblr instead of clicking all of that. The idea hit my head.
Every page-changing method in my website also can be called without login. Someone can input page-changing javascript code in the console without login and see the contents of pages.
The first idea came to my head to prevent this situation was, to send id/pw every time when I make a post request to the server and everytime server gets the request, server checks the id/pw to assign the browser to change page. For instance, when a user wants to go to menu A, he(or she) has to send his(or her) id/pw to see the content of menu A.
I thought this is such a bad idea. As I guess it will result overload in server CPU when the server always has to check id and pw(sorry, I don't know well about server CPU and process, this is just my supposition). So I guess there is another way to verify the user and their requests without sending id/pw every time.
Does anyone know about that? Or should I check id/pw with every post requests?
To answer you, you are talking about Cross Site Scripting. Let me first point you to some documents in order to make you aware of what you are dealing with:-
Its called Cross Site Scripting using which a user on the client side inject script in your website and change the different stuff on it.
https://en.wikipedia.org/wiki/Cross-site_scripting
Now to deal with such things there are remedies as following:-
CSRF Token
JWT
Both of them work in somewhat identical way but there are data and payload carrying capacity and encryption involved in JWT and I recommend that.
This is a very known problem in the community and is also pretty old.
On the other hand I will also recommend you to do a data sanitization before storing it into your database. Someone can easily input some JS in your site and you can be defaced in no time.
Have a look at this Sanitizing user input before adding it to the DOM in Javascript
Last but not the least. Stop exposing the functions in the Global level while writing JavaScript. Stop creating global variables and functions and rather use closures.
(function(){
var a =10;
var b = 20;
function add(msg){
console.log(msg)
return a+b;
}
add("I am calling from Inside the self executing function");
})();
add("I am calling from outside the self executing function");
Have a look at the code above and how it protects that add() method to be called from outside.
Hope this answers your questions.
Yes, on stateless scenarios you should send some client identification like a token and verify on the server. Don't worry about the performance :)
You could take a look to JWT: https://jwt.io/
To be specific, (although I am also interested in a general solution, if anyone would care to explain) I am trying to "click" Steam's 'Not Interested' button.
I have the urls of the pages I want to do this on in a Python script, alternatively I can write them in a file somewhere.
As much as I (think I) know about that button, it has no ID, and the relevant bit of code that is executed is:
$J.post('http://store.steampowered.com/recommended/ignorerecommendation/', {
sessionid: g_sessionID,
appid: store_appid
})
I am mostly unfamiliar with Javascript, but copying the headers and parameters, I managed to successfully send that post request (in Python instead), which worked. The problem with that is that it seems it requires the following cookies: steamRememberLogin, steamLogin, sessionid. I am rather sure those won't forever stay the same, and so my script would soon break.
I am unsure what to do from here on. I could imagine somehow automatically getting those cookies from somewhere, but where and how? Alternatively if something could actually send a click event from the button, I think that might be possible in Javascript?
And if this bit's important, then it doesn't need to operate in the background. As long as it can be scheduled, it's fine if it needs to actually open up that webpage in my browser.
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.
I want to user jquery ajax calls, for example;
function addnewteacher(){
$.ajax({
type: "POST",
url: "/actions/dboss/newteacher.php",
data: "uname=" + $("#newteacheruname").val() + "&upass=" + $("#newteacherupass").val() + "&name=" + document.getElementById("newteachername").value + "&surname=" + document.getElementById("newteachersurname").value + "&mobile=" + document.getElementById("newteachermobile").value + "&email=" + document.getElementById("newteacheremail").value,
success: function(html){
$("#response").html(html);
$("#response").dialog("open");
}
});
}
As you can see, i have to give away the data part to end user. But i want to encrypt it with a hidden function then decrypt it on server so probably no one can send and malicious code to server just because that code wont make any sense after decryption if not properly encrypted. But i have to hide the function from user or make the function work only for me?
Thanks for any help/idea
You cannot hide JavaScript code. It gets downloaded to the client and executed there. You can obfuscate it, push it way deep inside, whatever you want, but a determined user can still find it. Your security really needs to be on the server, where you have complete control, not on the client, where you have no control at all.
Make sure calls to /actions/dboss/newteacher.php are authorized and verify they are coming from valid sources on the server. Security through obscurity is not security.
No. You can obfuscate them by minifying the code and that sort of thing, but you should never ever assume that your javascript is unreadable.
You need to validate and sanitize any user-submitted data on the server end.
No, sorry that's not possible. Everything you put in javascript will eventually be visible to the user. No matter how hard you try to minify/obfuscate the code, suffice to install FireBug and the password will popout at user eyes like a balloon.
Everything JavaScript does can be done by a user. Even if you think noone will even understand you code, he doesn't have to. He can just execute it and see what it gives. JavaScript should only be used as a way to make the UI more convenient, not to secure anything. Basically, what you want to is not to write a password in the JavaScript and check it in here when the user types it but you want to send the password written to the server that either says "yes" or "no". If you check a form with JavaScript, you have to recheck it on the server-side because JavaScript could be disabled and so on. JavaScript on its own isn't secured (as client-side language of course).
You can use something like Google Closure to obfuscate the Javascript code, but I'd really look into why you need to hide this in the first place since they will be messing up their own data. As long as you don't rely on the data being valid for server side functionality (such as injecting the input directly into SQL) you should be ok.
You should be trying to hide keys, not the function that signs the content.
I've seen a number of JS systems that do something like this:
<script>// Runs first
(function () {
// Look for a key in the URL like 'http://mysite.com/my/path?my=params#;key=abcd...
var key = document.location.hash.match(/;key=([^;]+)/)[0];
// Make sure other code on the page can't retrieve the key.
// This is analagous to a program zeroing out its argv to prevent
// key retrieval via /proc.
document.location = "#"; // Does not cause reload.
// define signature algo and export to whatever scope is appropriate.
...
})();
</script>
Obviously, this only works with single-use keys.