if you are going to validate cakephp form using ajax, so not to reload the page, do you have to define validation array in the model? thank you.
You will always want to validate everything because you should never trust any input. This is a golden rule no matter what kind of program you write. Website or sensor. I would not even trust the input from a sensor for example and validate the data coming from it. Besides the server side validation you also should use the Security Component of CakePHP to secure your forms and site against attacks. You might want to use google to lookup a few attacks that the Security Component prevents, check the manual for a list.
Javascript runs only in your browser. You could simply disable javascript and enter whatever you want. Further you can edit the markup and add an additional input there and submit that changed form. Now make your guess what happens when you add a hidden field "role" and give the value "admin" for example...
Related
I'm making an asp.net app for user to enter database data. I want to make sure the data is valid e.g. certain field needs to have max 2 decimal or has max value of 100 etc. Do I check for valid data in javascript or in C# since I am using jquery datatable?
You should use both validations.
JQuery validation has a faster speed and it checks the validation on the client-side and didn't send any information to the server. But in many cases, users turn off the javascript of the browser and it's too dangerous if you don't check it by c#(server-side) validation.
You can also read the links below :
https://learn.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/client-side-validation
https://learn.microsoft.com/en-us/aspnet/core/mvc/models/validation?view=aspnetcore-5.0
you can go for both if you want. the client-side validation is not safe since can be disabled by client user but brings nice user experience since it prevents the form with invalid data to be submited at the beginning and avoid reloading or call any thing backend and keeps it idle.
How ever along side that implement server-side validation in case of client-side failure due to any reason.
if you want choose one of them .. of course it must be server-side.
I recently picked up NuxtJS en Vue to write a blog and wish to add a Google Recaptcha.
The best validation is a server side validation obviously. So before users can submit the form, the back-end needs to verify the google recaptcha response. I was wondering if I could do this through my Nuxt-app itself?
So instead of having a method that validates if there is a recaptcha response, I was wondering if I can write something in a special hook(maybe validate()?) that is unavailable from bots on the clientside but still checks if the recaptcha response is valid. Before sending the form.
Is this possible, is yes/no how and why not? Please enlighten me!
Cheers and thanks in advance.
Technically it might be possible to validate the Recapthca key on the frontend, but since you need to use your private key to do so, your private key would be exposed.
Also it shouldn't be the frontend's decision whether or not to submit the form based on a Recaptcha. The frontend should submit the form - and the backend should decide how to handle the submission based on the Recaptcha result. Otherwise bots would still be able to hit the endpoint.
My client needs me to implement captcha on his form. The form's action is set to an external page, to which we do not have access.
I wanted to use Google's reCaptcha but it seems that piece of code (which does the checking) needs to be placed in the targed page (which we cannot access).
What is the solution? I tried with using some simple Javascript array and jQuery checking of the value but it seems that spammers after couple of months learned how to dig the values out of the page code (yes, the values are written there, it's javascript - and I do not know better way) because the spam is arriving again.
A good client-side way would be even better. If you know a script or some code to be used here it'd be very appreciated.
Host another server with captcha and submit your form there. In case of success, submit the form from the captcha server to the one you don't have access to.
I am a web developer for a web site that is occassionally plagued by form bots. Recently I received an error notification of a problem with the form submission that should be impossible for a human user. You cannot submit the form without JavaScript enabled but the server side script received a form field value that the JavaScript validation will not allow.
I suspect that a form bot managed to submit the form without running the JavaScript but I'm not entirely sure this is the problem because a real user had a similar problem. I know how to use honeypot fields as a countermeasure for form bots but I need to test my countermeasures. Therefore I need a working form bot to attack my form so I can see what the result would be and to verfiy that my countermeasures will work.
I think you can use PHP with Curl to submit web forms but I can't find any sample code. I would prefer to use an actual form bot so I can be sure that the honeypot fields aren't easily circumvented.
Does anyone know what is currently being used to attack web forms? How do you test your countermeasures to ensure they are effective?
Personally, I use a FireFox extension called Tamper Data. You submit the form normally, but then you can modify the HTTP parameters (Variables, cookies, etc) before it's sent to the server. That way, you can manually change the validated fields. You could automate it with PHP and CURL...
The thing is, you don't want to run an actual bot against it, because that would only test one (maybe two) methods of breaking your validation. You want to run your own, that way you can test every possible combination that you can think of. If you automate it with PHP/CURL, you could then run the test with every change (an integration test) to verify that you didn't "break" anything... It shouldn't be too hard to write, since the CURL functions are pretty well documented...
What about captchas to protect your form?
I been reading on asp.net mvc learning site about JavaScript injection and man it is an eye opener.
I never even realized/thought about someone using JavaScript to do some weird ass injection attacks.
It however left me with some unanswered questions.
First
When do you use html.encode? Like do you use it only when you are going to display information that that user or some other user had submitted?
Or do I use it for everything. Like say I have form that a user submits, this information will never be displayed to any of the users, should I be still using html.encode?
How would I do it like I am not sure how to put inside say and Html.TextBox() the html.encode tag.
Second
What happens say I have on my site a rich html editor. The user is allowed to use it and make things bold and whatever. Now I want to display information back to the user through a label. I can't Html.Encode it since then all the bold and stuff will not be rendered.
Yet I can't leave it like it is since what would stop a user to add some Javascript attack?
So what would I do? Use Regex to filter out all tags?
Third
There is also another tag you can use called "AntiforgeryToken" when would you use this one?
Thanks
Edit
Almost everyone says use a "White List" and "Black List" how would I write this list and compare it to incoming values(examples in C# would be nice)?
Good question!
For the first answer, I would consider looking here at a previous asked question. As the answer discusses, using HTML Encode will not protect you completely against all XSS attacks. To help with this, you should consider using the Microsoft Web Protection Library (AntiXSS in particular), available from Microsoft.
As has already been mentioned, using a list of allowed tags is the best thing to do, leaving others to be stripped out.
The AntiforgeryToken token works to prevent request forgery (CSRF) because it gives the user a cookie which is validated against the rendered form field when the page is posted. There's no reason that I am aware of that means that you can't use this in all of your forms.
Use HTML Encode for any data being displayed that has been submitted by a user. You don't need to use it when submitting into the database otherwise you would get odd data like: Simon '&' Sons. Really I don't see the harm to use it on any content written to the page dynamically.
Use a list of allowed tags and discard everything else for your HTML editor. As people said, use a whitelist.
The third one is meant to prevent a Cross-site request forgery attack. You use this to stop people being able to do a POST using a 'stolen' cookie from the user. So you may require a authenticated cookie before accepting a post but a malicious user could take that cookie when a user visits their site and then submit a form to your site claiming to be them.
See here for more:
http://haacked.com/archive/2009/04/02/anatomy-of-csrf-attack.aspx
How to use it:
http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/
Always validate the input received against a whitelist. If you use a blacklist you could and probably will come up against encoding issues. Always use a whitelist when validating input.
Do not rely on client side validation to validate the user input. Client side validation is great for helping the user input correct data. But a malicious user will not use this and could bypass the client side validation. Client side validate is should never be considered as a security fix. Using javascript to validate input should not be used. As you can see javascript is very easy to change and modify on any html page. Also javascript can be disabled in browser. So give additional check in your code behind file.
Additionally validate the input every time, not just when the data is initially accepted. For example if you set a cookie, make sure that cookie is the same value and it is correct on each and every request. A malicious user could modify and change the value anytime during the session.
There are various levels of security that can be implemented based on the design considerations of your application.
I would go with the following basic rules:
Sanitize all input, removing known malicious sections (for instance, <script> tags in a rich HTML editor). Regex based pattern matching is commonly used for this kind of sanitization.
Remove all input that are not in your white-list of allowed values.
Encode any HTML before storing in the database and Decode it back when it is being retrieved for display.
Edit:#Phoenix talks about validation in this context so I thought I'd add this. I have said this before and I reiterate: I am not against script based validation. I only caution people not to rely on it expressly. A common design pattern is to validate basic criteria using script based validation and apply rigorous validation on the server side when that data is submitted.