This sounds like a bad case of Security Theater
Security theater is the practice of investing in countermeasures intended to provide the feeling of improved security while doing little or nothing to actually achieve it.
I say this because in all reality...
Given enough time, effort, and computing power security is nothing more than a delay.
Of course ...
This is relevant but doesn't necessarily answer 100% of your question:
The short of it is that as long as authentication isn't automatic (typically provided by the browser) then you don't have to worry about CSRF protection. If your application is attaching the credentials via an Authorization header then ...
Generally, CSRF happens when a browser automatically adds headers (i.e: Session ID within a Cookie), and then made the session authenticated. Bearer tokens, or other HTTP header based tokens that need to be added manually, would prevent you from CSRF.
Of course, but sort of off-topic, if you have a XSS vulnerability, an attacker could still access these ...
Previous answers are rock solid. I'll jump in here to provide a more context and little caveat. There are lots of ways to using JWT; session management is one of them. Although it presents a few drawbacks when dealing with timeouts and advanced requirements like re-authentication.
Also, I've seen JWT placed in Cookies. As other's have stated, CSRF ...
The bottom line is that you can't, but this is not as much of an issue as one might think.
The thing to keep in mind is that when you change the source in a browser's debugger (which is what you're describing), it doesn't get saved anywhere. This means that the change only affects the machine the debugger is running on. I can't change the password field to '...
With that said, as a hardening ...
The browser should be trusted with the user's data in any case. Whether you use a single-page app or a plain HTML page, you are toast if the browser is compromised. Single-page apps do not change anything in this context.
Single-page apps can however extend the potential of a server-side vulnerability - since you're now offloading some of the processing to ...
Angular users: Stop Saving UNSANITIZED User Input.
I have mixed feelings about the answer to my own question. As of Angular version 1.6, the Angular team has decided to remove the sandbox altogether. The sandbox (while not perfect) afforded the user some superficial level of protection against there own choices when building an Angular app. The sandbox was ...
Used to teach app pentest classes for a Fortune 20 appsec vendor to Fortune 100 clients. Years ago the state-of-the art for these types of assessments was the OWASP Ajax Crawling Tool where one had to manually input all of the Ajax parameters and actions.
For AngularJS, there is the AngularJS Batarang Chrome Extension in the Chrome Extension Store -- very ...
The primary security reason to avoid cookies would be to prevent CSRF attacks, which is a valid goal. Cookies were not well-thought-out from a security standpoint. On the other hand, there are well-established approaches to avoiding CSRF, so it's not a hugely valuable technique.
From a privacy standpoint, cookies (especially third-party cookies) are ...
As stated on angular's security page, interpolated content is always escaped. Unless the application explicitly marks the content as trusted using the DomSanitizer or there is a vulnerability in angular, there is no way for an attacker to exploit this.
You don't understand what you are doing. All PHP code (and also the backtick/exec/system commands) is executed on the server.
There is no portable/reliable way to get the MAC address. Maybe a browser plugin could do that.
Consider that the client can also not have any MAC addresses at all. For example when connecting via PPP.
Considering that you appear to only Base 64 encode the email, it's easily bypassed.
Don't try to reinvent the wheel, especially for security.
Use a well known authentication library.
After a user is authenticated, then retrieve data about them from storage based on their authenticated identity and pass that on as required.
Edit If you want to persist ...
You are trying to achieve security through obscurity, and it won't work.
There is a bit of a fundamental security issue here based on the fact that an attacker can inject an Angular expression. The Angular project itself has actually stated that the sandbox is not actually a security mechanism, despite the name, and removed it in newer versions to avoid this confusion:
You have an ad-blocking browser extension which is injecting this CSS stylesheet into pages you view. (To be clear, this stylesheet is used to block ads, not to display them.)
This is harmless, and only affects you -- it won't affect others users viewing your site. If it's still bothering you, though, you can disable the extension for this site, or switch ...
[AngularJS] Common Pitfalls
AngularJS makes it very easy for developers to get in to some dangerous territory. Here's some common things that I see when I assess websites using AngularJS, regardless of the backend:
Lack of server-side session validation
Lack of server-side input validation
Decoupling the frontend from the backend and forgetting things like ...
For Angular.JS, there is a very handy tool Batarang Chrome Extension in the Chrome Extension Store:
For testing REST you can still use Burp, Fiddler or ZAP.
Here is a link to REST OWASP cheat sheet:
It sounds like you're mixing scopes a bit. Angular is a front-end technology, and while you can escape HTML to prevent XSS attacks, any basic templating language can handle that.
When you think about security in a web app, you have to remember that the end user is free to run whatever code they want on the front end, and they can hit your APIs in custom ...
If I can try to interpret the question to answer 'I suspect that you can reach an adequate security with Angular if you know what you are doing, yet many of the issues with Angular that you could have to watch out for is more or less built-in and fixed if you use .NET alternatives such as MVC.'.
And yes, its not a fair comparison. Server-side and client-...
This is the intended design, and not an issue, except when site authors forget that this is the intended design.
You can get the version number from the JS file itself.
Header of the current angular.js:
* @license AngularJS v1.0.6
* (c) 2010-2012 Google, Inc. http://angularjs.org
* License: MIT
You can search for this file using the console of your browser as well.
You can use Chrome's Inspector to view the DOM tree as HTML. There you see the rendered result of the AngularJS processing.
But provided that you use AngularJS correctly, it takes care of all escaping and won't allow any XSS vulnerabilities (otherwise they are vulnerabilities in AngularJS itself).
You need to use $sce and ng-bind-html to make AngularJS ...
The difference with your token (base64 encoded email address) and a JWT is that for a JWT it is much harder to create a token for another user. With your token, I can easily encode any other email address and obtain a valid token. A JWT, however, is cryptographically signed so that you can only create one if you have a secret key, that remains on the server.
There's no reason you can't do a security sensitive website in AngularJS or Angular2 - for the most part, the key points of security happen server side, not JS side. Yes, of course, you need to do some XSS and CSRF protections on the client (in conjunction with the server), but that is very doable in Angular/Angular2.
Whatever the client, the server needs ...