I have a form where users can buy credits with PayPal or banktransfer as payment option.
If a user selected "PayPal" as an option, the form data will be send to PayPal, using JQuery/JS:
$(':radio').change(function () {
var $this = $(this).val();
if ($this === 'pp') {
$('#form').attr('action','https://www.paypal.com/cgi-bin/webscr');
}
else
{
$('#form').attr('action','');
}
});
The user can also choose how much he wants to pay, which also selects how many credits he'll get from it. Additionally he can add a coupon-code. An Ajax-Request will check our database, if this is a valid coupon and grants the discount-value then.
All informations are stored in hidden input fields (what the price is, how many credits, how much discount (if any), user id, etc.).
Now, I want to make sure that the user doesn't manipulate these values with Developer Tools or similiar things to pay less, use another user id and so on.
What would be the best possible way to prevent this form manipulation and receive the correct data? I assume it's kinda difficult because there are so much values to change.
Data Forgery / Manipulation
There are many nefarious means of sending manipulated or forged data to a web server - cURL, Http Client (OSX app) just to name two that I use frequently when debugging. A determined attacker will send bad data to the HTTP server no matter what Javascript you think up.
Think outside the box
For security needs, it's time to break out of the mental model of using a web browser because it's a web site. As already stated, there are many ways to send data to an HTTP server.
Javascript is good for the UI and helping the user, but when it comes to securing your service against intentionally bad/wrong/malformed data, you must do that on the server.
Your particular problem
You may need to re-think using hidden form fields. One approach would be to use sessions to keep track of this info. If this is information that must be sent to PayPal in their form, there is a way to embed the PayPal form using encrypted data.
If you don't want to do this, the point of security then moves to the order processing code - look at the transaction details (currency amount, etc) before considering that a transaction is complete and valid.
Related
I'm pretty new to HTML, like 1 week new. I am making a web store and I want to be able to login into an "admin panel" to make it easier for me to manage my products. Add new, remove, rename etc. My problem is, I have my login information stored in the html code and I use if-statements to check the validity.
When I was testing the code, I was curious and wanted to inspect element. Unsurprisingly, there was my entire login information and anybody can have access to it.
I need to somehow hide it, or hide the login fields from users except me. But I do not know how to approach that. I thought of a few solutions like have a hidden part on the store page and if I click it a certain amount of times then it will show the fields. But I think I'm complicating it.
Any ideas are greatly appreciated. Thanks. Below is my function for logging in.
function login()
{
var username = "test username";
var password = "testpassword";
if(document.getElementById("username field").value == username && document.getElementById("password field").value == password)
{
var btn = document.createElement("BUTTON");
document.body.appendChild(btn);
<!-- hide the user name field after login -->
document.getElementById("username field").hidden = true;
<!-- hide the password field after login -->
document.getElementById("password field").hidden = true;
<!-- hide the login button after login -->
document.getElementById("login btn").hidden = true;
<!-- show a message indicating login was successfull -->
window.alert("Login successfull! Welcome back admin!")
}
else
{
window.alert("Sorry, you are not authorized to view this page.");
}
}
And this is a screenshot of the inspect element. I don't want anything too crazy like a database because I'm the only user, just a way to be able to access the admin panel without exposing myself. Thanks again.
Inspect Element Screenshot
EDIT:
I am not using my own server, I am using Wix.com to make the initial website and then using the HTML widget to create a webstore. I don't think they allow people to have any communication with their servers whatsoever.
Username and password validation should never be done on the client side. It should always be done on the server. Do not use javascript for this task. Allow your user to enter their username and password in a form, and then submit the form to a server side script to validate their credentials. Doing it on the client side will never be secure.
There's no easy solution to your particular request, but before I oblige you with the details I'd like to stress three very important points.
1: Javascript is not Safe
Javascript is a client side language, which means every piece of data you'll ever be dealing with that comes from your user can be directly modified. These include, but are not limited too, any values or attributes of HTML tags, inline Javascript, loaded image files, etc. Essentially, anything that is cached on the user's computer can be modified and might not be what you're expecting to receive.
As such, a Javascript authentication system is absolutely not safe by any definition of the word. For a local page that only you can access, it would do the job, but that begs the question of why you need authentication in the first place. Even then, as a new developer you'd be widely encouraged to never try do it anyway. There's no point practising and learning how to do something in a completely insecure way and nobody is likely to suggest it.
2: Authentication is a tricky topic
Authenticating logins is not an easy thing to do. Yes, it's easy to make a login script but it's not easy to do it properly. I would never try to discourage anyone from making something themselves nor discourage a new developer from pursuing any goal, but authentication is not something you should be learning only a week into HTML. I'm sorry if that comes across as harsh, but there are people who have been masterminding applications for years who still don't do it securely.
3: Third Party are Best
It's possible to make your own authentication system that likely only the most determined of attackers could access, but it wouldn't involve Javascript authentication. Consider Javascript to be more of a convenience to the user than a solution for the developer. Javascript can do some remarkable things, but being a trusted source of data is something it will never do. Please understand this important point, because the source code you have provided is riddled with security flaws.
--
Now, on to what you want to do. Identifying that you're the "admin" user is something you're putting a password in to do. If you could figure out you're the owner of this site before putting in your password, you wouldn't need the password, right? In short, you can't do what you want to do; not reliably, anyway. It's possible to only show those forms if you're using a particular IP, but IPs can be masked, imitated and changed, which makes it insecure.
There are several third party authentication methods that you can use to do all the heavy lifting for you. All you do is put the fields on your page and they'll handle the rest. You can use any Social Media login (Facebook, Twitter, Google Plus, etc) or you can use O Auth, which deals with all the heavy lifting of authentication for you.
I don't mean to discourage you, nor anyone else, from pursuing their own authentication methods but if I'm honest with you I think this is something way beyond your skill level that you shouldn't be considering right now.
If you serve the pages via a server, you can enforce basic HTTP auth. Should be really simple to set up and you would have the benefit of a standard of security.
Here are the Apache docs for this, for example.
I am looking for a way to use AJAX and jQuery to store data from one form in another without losing the values. I want to be able to keep this data away from the front end user and allow them to remove the information should they wish to. I need to be able to get this information out when the user submits the data. I would like to be able to store the values in an associative PHP array if possible, for example:
<?php
$information = array(
"first_information"=>array(
"name"=>"Sam Swift",
"age"=>21
),
"second_information"=>array(
"name"=>"Example Name",
"age"=>31
)
);
?>
I would have used a database for this but because of volume this will not be possible. I want to keep the data away from the user so that they have no access to it at all, the data should be held where the user has no way to see it, access it or change it. This is due to the nature of the data and all of it should be as secure as possible.
Any information that you store client-side is naturally going to be accessible and mutable by the client. If this sensitive data is data that the user is entering, then you really shouldn't worry about them manipulating the data (because that is what they are supposed to be doing). If however it is data that is being sent by the server - and never displayed or used in that form by the client - this is data that should never leave the server in the first place.
Ajax is not specifically a solution to this problem - whether you send the data asynchronously (i.e., piecemeal with Ajax) or as a full HTTP post is immaterial. You need to store the sensitive data on the server only along with a session ID to associate it with the client session.
Without knowing exactly what data you are storing nor what you are doing with it, it is difficult to advise you how to proceed. You should rethink how you are structuring your application if you are sending sensitive data for the client to work with. The client should only ever see the input and the results. The processing should be done on the server.
For example: perhaps your user is adding an amount to a bank balance. The user enters the amount on the client. but you don't want the client to see or be able to modify the actual value. You could send the balance to the client, perform the addition operation, then send the total back to the server. Far better would be for the client to send the amount to add to the server, which would then add the value to the balance, and return a confirmation for the client to display.
I am creating a registration form that uses JavaScript to calculate an amount and uses method="post" to redirect the user to PayPal to complete the transaction. The piece I'm missing is some way to capture the information before sending them off to pay. Ideally emailing a copy of the information or even saving to a text file on the server.
I'm kind of a n00b here, so while I realize it's possible to post to my own PHP script and have that redirect them to PayPal, I'm not sure I'd be able to figure out all the pieces in that workflow. Is there a simpler way to do it?
Well you can save your form values into a database and then send it to paypal but I need your html to give you appropriate PHP code.
You need to be careful, if you're saving credit card information you need to make sure you are not breaking the law and/or have the necessary credentials (e.g. PCI compliance)
Paypal also has a function where it will notify a URL, that you specify, when the transaction has been processed. It will give you a summary of the transaction. You can then use that to perform post-payment operations, e.g. change your order status, send email...etc.
Upon completion of an ajax call I would like to direct the user to an html page, but at the same time passing a hidden variable (this variable contains sensitive information and should not show up in the URL).
How can I accomplish this?
window.location.href = 'userpage.html?id=14253';
But with the id remaining invisible? Can I POST the id somehow while sending the user to userpage.html?
You should not be checking user credentials on the client side of your website. Regardless of how the ID is being passed to your script, it can be replicated without you being able to check if the request is valid.
To start being even remotely secure with what information is granted to a user, you need to be checking it via the server side. With every request, ensure the user is authenticated to view such data.
If I were you, I would look into using PHP sessions as the first line of defense for checking if a user is authenticated. Doing so will at least keep the information about a user out of a replicable space that can be viewed by the user.
Look up 'php session login tutorial' on Google and you will find plenty of simple tutorials which should get you on the right track.
Example Tutorial
No matter what, the information you pass along is insecure. You can submit a post request using XMLHttpRequest objects if you'd like (or use a framework/library to make AJAX calls) -- but the user could still spoof the data and get different results.
ID enforcement should be done in the backend. Does the requested ID match the ID of the user signed in? No? Don't show it. etc etc.
Take Facebook's reply-to-status as an example. When you replies to someone's status, does the script looks into the DOM of that status for the ID of that status, and send an Ajax to update the entry with that ID?
If that's the case, couldn't you just modify the ID and pollute the data
P.S. as a followup, I've seen a client-side MVC implementation, Backbone.js, that manage things like the above w/o the use of any ID, which I still haven't figured out how.
http://documentcloud.github.com/backbone/docs/backbone.html
Here is the source, the relevant code 'view' starts at last 1/4
It will still verify that it's a valid id on the server side, that you have permissions to follow up to that user's statuses, etc.
Yes you can, but keep in mind it's all session/friends list/permissions based too.
There are still checks involved on the server regarding "does user A have access to making a comment on user B's action". Assuming you type a bogus ID, it still needs to be verified you can post on the (spoofed) ID.
If you can, you just made a post on a completely separate topic which is now presumably out of context.
If you can't the post doesn't go through and no worries.
What it comes down to is that the UI is a "convenience" check. There's not real integrity to validating other than gently guiding the user to travel the correct path. The server is where the real protection is because, as every real programmer knows, the user can not be trusted.