I have a beginner question about produciton mode in vuejs. I'm using the minified version of vue and i have a Question. How can i avoid accessing and changing the value of data by using DOM here an example: for accessing -> document.getElementsByClassName('VueInstance')[0].__vue__.$children[0].$data.foo and for changing document.getElementsByClassName('VueInstance')[0].__vue__.$children[0].$data.foo = "bar" ? Its there any possibility to do it ?
You can't.
Client-side JavaScript isn't secure by design, i.e. user has full control over the script that runs in user's browser. Considering that a user has enough access rights locally, the code always can be read and modified. Security measures that are applicable to client-side code only make this process more complicated.
Never trust anything from the client. The client can change whatever they desire, and can even edit the data that's going to the server. If you wish to ensure they can't do something, then you will have to put checks on the only thing they can't change
How to prevent the user from changing values in the HTML or the JavaScript
Can react state be tampered with to bypass security measures?
Related
In my Sitefinity back-end there is a user section that I would like to add some setting. Something like DisplayLink where it would be a boolean value that I can set on Login of the user. Is there a way I can do that? I am using sf 14 and can't find anyway to add some setting for the user.
I believe this is what you need ...map the view externally and modify.
However keep in mind these views pull in the XHR JSON and you just expose it to the grid... Open your console and view the XHR network traffic to see the JSON object per user. There's a "Comment" field you might be able to leverage, but man the best way would be to just use a ROLE... because they can be filtered, and already come across in that JSON.
Another thing to note, is this is an OLD UI screen and likely will get revamped in the next few releases of Sitefinity rendering everything you're doing pointless... (have to re-do it with likely the new AdminApp Extensions)
I am developing an identity server 4 dotnet core application so this is as much as a dotnet question than and IDS4 question. One example of state I need to maintain between pages (login, signup etc...) is the returnUrl. The application I'm migrating from used to store it in a session variable but, as I understand, unless I run a persistent session strategy, this won't scale well.
So currently, I'm passing it around as a field in each View Model used by each view so it can be returned. Is this a sound approach? I'll be needing other fields to be passed around as well so I'm wondering whether this is a secure and logical way to do it.
So currently, I'm passing it around as a field in each View Model used by each view so it can be returned. Is this a sound approach?
Yes, how you choose to pass it around is up to you, I choose this same approach. You could use TempData, Sessions or even localStorage as an alternative. I think having it in the models (view models) is a good approach because you are explicitly specifying where you want the return url to exist, otherwise it might persist in context that you wouldn't want.
Now the security question because obviously you might be able to see the return url in the browser address field.
As part of Identity Server 4 setup you specify which return url's you are allowed to redirect back to, so I don't think there is any harm in having the users see the redirect url.
Something to consider is what if the user would share the url to someone else in the middle of the authentication process, would they be able to resume from that part of the process that the initial user has stopped? is this something you want in your app?
If you mean reliably instead of securely, write tests which will provide you with confidence that your code works.
I'm trying to a CSRF protection to an existing MVC4 web application which uses DevExpress grids. I've added the Html.AntiForgeryToken() into the forms on the aspx pages (which contain ascx as partials containing the grids) and can see the __RequestVerificationToken and it's value clearly in developer tools when a save is called.
I've tried commenting out all my ValidateAntiForgeryToken attributes bar one - I went with the delete post method for simplicity (And also to eliminate the DevExpress grids messing with it) and I still keep coming up against this error:
There was a HttpAntiForgeryException
Url: http://localhost:54653/Users/Delete/f86ad393-0039-44e8-beed-a66dbab9266e?ReturnURL=http%3A%2F%2Flocalhost%3A54653%2FUsers
The exception message is
The required anti-forgery form field "__RequestVerificationToken" is not present.
Does anyone have any idea why this might be happening? Could it be that the error is non-descriptive and it's actually that the token doesn't match rather than that it doesn't exist? In previous answers to this question people just say "oh, you have to add the token," which is obviously not helpful here.
Are you submitting the form manually through Ajax? If that's the case, you need to pass the anti forgery token as another parameter with the name "__RequestVerificationToken".
Point 1 : Make sure if your application is has https secure protocol. Please load in https.
Point 2 : In case of DevExpress you have to call in the below pattern.
ViewContext.Writer.Write(Html.AntiForgeryToken().ToHtmlString());
After struggling with this for days I had a thought - maybe the browser is stopping the cookie being written. I did a search for dev servers and cookies not being written, and found that with Chrome and IE10 and up that there's problems writing the cookies.
I downloaded Firefox and tried it with that and it worked instantly. I then reapplied all the validate attributes to the all the controller methods and the all worked, every single one of them! Even the DexExpress postbacks seem to be working correctly.
I'll carry out more exhaustive testing, but for now, I think we're there.
Not exactly. If MVC AntiForgeryToken is already defined on page where you are using MvcxGridView and you want to protect grid actions you should send this token back to server during grid client side begin callback event.
settings.ClientSideEvents.BeginCallback = "function(s,e) { e.customArgs[\"__RequestVerificationToken\"] = $('input[name=\"__RequestVerificationToken\"]', $(s.GetMainElement())).val(); }";
atm i have a JSP (my Host page) where i set the Session id via scriptlet with the Request Object. I save this Information in an hidden field and read it with the gwt DOM Object. Is there à better way to do this ? Thanks in advance for help.
Kuku
Depending on your setup this is a valid way to get a hold to a session ID. I assume you have written just a part of you web application in GWT and integrate it into something bigger written in some other language. Since your host page is JSP, I assume the non GWT part of your application is also dynamic.
I don't think that the proposed solution using a GWT service call works in this case. Since you can not match the session ID on the server to the incoming AJAX call.
Instead of using a hidden field, you could encode the session ID in the URL and get it from there, see getParameter(...):
http://google-web-toolkit.googlecode.com/svn/javadoc/2.2/com/google/gwt/user/client/Window.Location.html#getParameter%28java.lang.String%29
But I actually prefer the solution with the hidden filed, because it does not affect the URL. If you encode transient information in the URL you may lose the ability to bookmark it.
I have an injection script--a start script--whose ultimate goal is to redirect to a different URL. That injection script needs to access the extension settings, so it sends a message to a global HTML file. That global file checks the settings and redirects to the appropriate URL by setting the safari.application.activeBrowserWindow.activeTab.url property.
What I'm finding is that all too often, the interim page loads first making for an annoying UX at best and introducing errors at worst. I'm assuming that this is a result of the asynchronous nature of messaging, but I haven't been able to find a way to stop it.
Is there any way to prevent the default behavior (loading the originally requested page) while still reading from extension settings?
Thanks.
It looks like this simply isn't possible given the current state of the Safari extension API.