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.
Related
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.
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'm trying to embed a value into the textbox at the USCIS government website to check my application status number. Suppose it's LIN1234. After inspecting the element of the webpage I see that the HTML wrapper for the textbox is:
<input id="receipt_number" name="appReceiptNum" class="form-control textbox initial-focus" maxlength="13" type="text">
I tried opening up this URL with a suffix added on, but to no avail:
https://egov.uscis.gov/casestatus/landing.do?receipt_num=LIN1234
Is there a way to to this?
Before that, you must understand what means adding ?receipt_num=LIN1234 to the url.
When sending a request (By default and in this context) from your browser, it'll be a GET request (see here) where you send as a get argument your receipt number, setting its key to receipt_num.
What is done to this data on the server side, however, is up to itself.
Just understand that unless the server is made to auto-fill the field with that value in case it receives it, it won't do anything except sending some more data.
I think you want to load this page in your browser with auto-filled field.
In that case you should look into extensions for your browser that would do that automatically.
You probably won't be able to embed a value into the textbox... Just because you are sending values by GET (which is what the landing.do?receipt_num=LIN1234 syntax is doing) doesn't mean that they have something set up to process it, so the GET variable will probably not do anything.
You might be able to see how their URLs work ordinarily, what the page URL that you are aiming to land on looks like, and either decode something from that or set a bookmark there. That said, if they are submitting that data via POST (which they probably are, for security reasons), that probably won't work.
I would suggest looking at reputable form-filling plugins for your web browser, if that's an option. That might allow you to work around that.
What are the benefits (if any) of using type="password" vs. type="text" when creating a form for account creation on a website? Besides a create and confirm, is there a defined best practice?
The obvious reason is, that you can type the password, even if other people are watching the screen. Often i have this situation when i publish my desktop in a presentation, or if i need to give support to other users.
Besides hiding of the characters, the browser (or desktop application) will also prevent copying the content from the password box. This is one possibility less for other applications to misuse the passwords.
I might me wrong but as far as i know the only benefit of using type="password" is that another person can't see what you're typing. But the value behind that is transfered in plain text if you dont use https.
If you use the password type, the text will be hidden by black dots (or * or .) whilst text entries are displayed in plain text.
Also, if you're using forms with passwords, make sure to use HTTP POST as opposed to HTTP GET. Because on the latter, the entries are visible in plain text inside the options section of the URL (see the difference between HTTP GET and HTTP POST there: http://www.w3schools.com/tags/ref_httpmethods.asp).
You can do that by specifying method="post" as an attribute of the <form> tag.
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 :)