32

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 ...


28

This is relevant but doesn't necessarily answer 100% of your question: https://security.stackexchange.com/a/166798/149676 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 ...


19

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 ...


10

There is no way to prevent an attacker doing this if they are already accessing the developer tools - they can simply pause the javascript and continue what they are doing. The best you may be able to do is clear the password box after a small amount of inactivity.


7

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 ...


5

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 '...


5

So I'm guessing the drive of your question here isn't whether the JavaScript files are obfuscated or not but rather whether they're accessible pre-authentication? If that's the case then I'd say it shouldn't be an issue as the JavaScript is sent client-side and therefore no sensitive information should be embedded in it. With that said, as a hardening ...


4

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 ...


4

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 ...


4

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 ...


4

You cannot get the MAC address from the machine where the browser is running on by executing Javascript (and thus also Angular.js) inside the browser. Access to this information is restricted due to the sandbox in which Javascript is executed.


4

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 ...


3

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.


3

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.


3

You can not do this because all things are happening on the client side and he has almost full access to your code (html, css, javascript) using developer tools. So, he can pause or stop javascript.


3

If you're really worried about this, you could do away with passwords entirely in your application. Have the user enter their username or email and send them an email with a temporary login link.


2

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 ...


2

You can't. The form needs to be able to send the password to the server for validation. Even if you develop some kind of obfuscation technique (not recommended) then, like William Dunne said, you can simply pause/stop Javascript. You are trying to achieve security through obscurity, and it won't work.


2

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: http://angularjs.blogspot.com/2016/09/angular-16-expression-...


2

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 ...


1

tl;dr: Encoding should be done at the time the data is being used in context - when the code is composing HTML, javascript, etc from untrusted data - that's true whether you are composing on the server or client. At that point you know what parts are data, and what the encoding context is. You should leverage binding (ng-bind) in Angular for context ...


1

[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 ...


1

For Angular.JS, there is a very handy tool Batarang Chrome Extension in the Chrome Extension Store: https://chrome.google.com/webstore/detail/angularjs-batarang/ighdmehidhipcmcojjgiloacoafjmpfk For testing REST you can still use Burp, Fiddler or ZAP. Here is a link to REST OWASP cheat sheet: https://www.owasp.org/index.php/REST_Security_Cheat_Sheet


1

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 ...


1

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-...


1

This is the intended design, and not an issue, except when site authors forget that this is the intended design. In a web application, Javascript must be readable by the browser, because that is where it is parsed and executed. And anything that's readable by the browser is readable to an attacker. Therefore, the security of the system cannot depend on ...


1

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.


1

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 ...


1

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. ...


1

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 ...


Only top voted, non community-wiki answers of a minimum length are eligible