I'm learning to use a payment method via SCI.
and for that I have to send a POST/GET request to The SCI.
everything is working fine. the payment goes well.
but when I open the page and inspect it, I can see The input fields of the form. (type-->hidden) then using the edit HTML I can change the amount as you can see in the image bellow
<input type="hidden" name="amount_USD" value="60" readonly>
the readonly does not do the job! how can I make HTML Code unchangeable.
or if there is any alternative way to code this in a more secure way.
You can never make client side code completely protected, because there are many tools one can use to manipulate the files. Anything from browser extensions to developer tools can do this. Code that can be modified includes HTML, CSS, and client-side JavaScript.
If your app/website relies on this type of security, it will never be completely secure.
Chrome Dev Tools is only one example of a way some could maliciously use your app. You should evaluate your security practices from the back end to front end.
There is nothing you can do to prevent the user from being able to edit the HTML on client (browser). You should implement server side validation to reject invalid data.
You can read more about it here: JavaScript: client-side vs. server-side validation
In this particular case, you could do something that rejects the amount received from client if it doesn't match on the server. Or, do not receive the amount from the client at all, if the client should not be able to change it.
Related
I am concerned about web security and the use of the HTML5 required word on input tags. I am trying to use it as part of 'form input validation'. Is the use of the HTML5 'required' on input tags something that is reliable for validation or is it easily manipulated by a user trying to bypass the input field requirement.
I have searched for information on html security and found little on this.
Thanks
In short, the answer is no, client side code is not a safe place to rely on security checks.
The method of using required provides the user with feedback and allows for a nicer user interface, but for security you will want to perform fidelity checks on all data passed over to the server side, how that is done depends on your backed architecture.
To answer your question in the comments, the required attribute is there to prevent the form being submitted without the field being complete, this is however purely to help the user know it is required. If you have a hacker simply remove the required attribute from the markup, then they're up to no good anyway and that's where a backend check will save you.
In my Opinion it is not an effective method. Required attribute can easily be changed using inspect element on that field on the browser.
The main thing here is to keep in mind that all client side validation is your first line of defense but most of the time you need an extra layer to check on your server side.
I could make an http post request to the action field of your form without using your form at all with tools like postman (chrome extension) if your server doesnot have extra validation then you are not safe.
I have the following html code:
<input type="text" value="test value" readonly/>
This input element is non-editable since it has the readonly attribute. But it's still possible to make this field editable by inspecting the element using the Firebug tool in Firefox. Is there any way to make this attribute non-editable?
This is really not possible. Someone will find a way around it because your code is executed on the client. Even if you secured the client (web browser) there is still a way to post back and tamper with read-only fields using a proxy server like Fiddler. You have two choices.
1)Remove the item from the field list and make it a text element. This is only a valid solution if you don't need the information back in the POST.
2) Keep the item read only (or hidden) but check the content has not changed on the server side. This is a best security practice anyway. You should always validate on the server even if you validate on the client. The reason is that people can work aound client side validation. There are different approaches for server side validation according to your back end language. In this case, if you are using PHP or ASP.NET, then you can stick the value in a session variable before you serve the page and check the POSTED value against the session value when the form is submitted.
Like you can go on http://whatsmyuseragent.com/ website and see what user agent you are coming from. I need the similar feature on my website. I tried to view source and didn't find nothing. I am basically looking forward for the html code to find the user agent of people that come on my website, I am just debugging at this point. I am looking to put the coding on my home page so that I can confirm what device the user is coming from. Can anyone help me with this?
HTML is not a programming language. It has no means to get this information.
The proper approach is to read the User-Agent HTTP header using a server side language (and optional web framework) of your preference (e.g. in Perl/Catalyst), and then output it to the page (after sanitizing it to make it HTML safe).
Similar data is also available to client side JavaScript via the navigator object.
The user agent can be whatever the user wants it to be - so don't rely on this for security.
From the client side, you could use some JavaScript in your HTML:
<script language="javascript">
document.write(navigator.userAgent);
</script>
I don't recommend using document.write though.
For the mentioned web site, they're likely checking server side with the HTTP header. To grab this in PHP, you can use:
$ua = $_SERVER['HTTP_USER_AGENT'];
But as Quentin said, sanitise this as it could output anything the user likes.
How can i limit my form to only accept jpeg files? Now it shows all files.
<input name="image" type="file" />
And are there any javascript method to show progress?
There is an accept attribute in the input tag, but it's not supported by all browsers. Here's an example:
<input type="file" name="image" id="image" accept="image/jpeg" />
It could be your first check, but your main check must be on the server when accepting the file.
How can i limit my form to only accept jpeg files
Mostly, you can't. You have to check at the server (which you need to do anyway, even if you can check at the client; you can never trust client-side validation, of anything). But things are improving. There is the new File API from the W3C coming down-the-pike, which you could use on browsers that support it (Mostly Firefox, at the moment; it was a Mozilla initiative), just for a better user experience for those with modern browsers.
Edit And Gert G points out that here's the accept attribute that can give a hint to the browser, which is nice for browsers that support it.
And are there any javascript method to show progress?
Not directly, no. It's sometimes possible to show progress indirectly, by using a timed series of ajax requests alongside the upload and having the server tell you how much it had received so far, but it's fraught with difficulty and probably not worth the bother.
This is another area where the file API could help, although you might find you introduced a fair bit of latency in the process: Basically, you could read a chunk of the file locally, send that to the server via ajax, update progress, read and send the next chunk, etc.
There are, of course, Flash uploaders like SWFUpload that show progress and such, if you want to use something proprietary (but incredibly widespread). (Flash, I mean.)
There is no pure html way to show certain file types, and there is no easy javascript way either.
I use a package called FancyUpload: http://digitarald.de/project/fancyupload/ which handles this part for me. Also, it will show the download progress bar as you've asked.
I should mention that the uploader I posted needs you to include a javascript framework called MooTools. There are other similar uploaders available if you prefer jQuery (such as uploadify) or another framework.
Please, make sure that you also check on the server side.
This can't be done in plain HTML/Javascript, but there are several Flash-based components that can do this - e.g. Uploadify comes to mind.
If you can live with this limitation, there's plenty of questions about this (with good answers) here on SO.
You can use <input name="image" type="file" accept="image/jpeg"> to limit the users choice. But you still need to check the file type in the server.
You can obviously not display progress without starting the upload, so you should be first looking for a server side api that keep the client updated on the state of the upload. As for javascirpt progress bars every javascript library has one e.g. jquery progress bar
I read some AJAX-Form tutorial like this. The tag form is used in HTML code. However, I believed that it is not necessary. Since we send HTTP request through XmlHttpRequest, the sent data can be anything, not necessary input in form.
So, is there any reason to have form tag in HTML for AJAX application?
Apart from progressive enhancement as already discussed (don't make your site require JavaScript until it really has to), a <form> with onsubmit would be necessary to reliably catch an Enter keypress submission.
(Sure, you can try trapping keypresses on separate form fields, but it's fiddly, fragile and will never 100% reproduce the browser's native behaviour over what constitutes a form submission.)
Sometimes, web apps using ajax to transform their data either use forms as a fallback when the user has no JavaScript enabled (a sometimes expensive but very good thing to do).
Otherwise, if an application builds and sends an AJAX request, there is no compelling reason to use a form except in rare special cases when you actually need a form element. Off the top of my head:
when using jQuery's form serialize function
when monitoring all fields in a form for changes
when there is need to make use of the reset form button (that to my knowledge is available in a proper <form> only).
I see at least two possible reasons :
Graceful degradation (see also Unobtrusive JavaScript) : if a user doesn't have Javascript enabled in his browser, your website should still work, with plain-old HTML.
Behavior of the browser : users know what forms look like and how they behave (auto-completion, error-correction, ...) ; it's best not going too far away from that
And I would add that, if you want the user to input some data, that's why <form> and <input> tags exist ;-)
Using the right tags also helps users -- as an example, think about blind users who are navigating with some specific software : those software will probably have a specific behavior for forms an input fields.
It really depends what you're doing. If you're wanting to take form content submitted by the user and use AJAX to send that somewhere then you're going to want to use the form tag so your user can enter their data somewhere.
There will be other times when you're not sending data from a form and in that case, you wont have a form to be concerned about :)