Allow custom prefix instead of q- for css classes (for built-in components, not custom)
-
You said, “it’s easier to exploit sites when the selectors are predictable or the framework used is obvious”. It’s a fallacy to think renaming classes will get you better security.
Scott
-
The attack I speak of is something I’ve done to my friends in high school by letting them install my emoji extension for chrome and the only way to prevent it is to have obfuscated classes and ids
-
Is it possible to get quasar/vue class names to be things like _8Qm7L instead of q-field__native like when I am using react?
-
So, are you saying, Quasar is going to put in a back door or some other security leak and you want to make sure Quasar doesn’t notice you are using Quasar to avoid Quasar hacking into your site? That’s ridiculous. Sorry, your reasoning on “hiding” a possible attack vector makes no sense.
And where does React obfuscate its CSS naming automatically? It doesn’t. So, stop saying that. And, if you have gotten React (or rather Webpack) to obfuscate CSS class names, then you should have the knowledge to do the same with Vue/ Quasar.
I don’t have an answer for you, as long as you keep saying renaming the CSS is for security reasons. I won’t offer you something under the pretense of better security, when in fact, it would be far from being more secure.
Scott
-
Again, you misunderstood what I was saying. Its not about Quasar specifically, its about IDs and classes. I only mentioned Quasar because its the perfect framework to me (not joking) so I assumed it had something built in to achieve what I want to achieve.
I didn’t say React obfuscate its CSS naming automatically
Facebook and Google does it using a minification process
https://develoger.com/how-to-obfuscate-css-class-names-with-react-and-webpack-20e2b5c49cdaLet me give an example of one of the attacks my chrome extension did…
I added the class for the selector of the yahoo mail recipient field and the send button to the script which then (in less than a second) adds my “capture” email address to the field when my friends press send then removes it from the field within that sub-second… this allowed me to get a copy of their emails… if it was a case where yahoo changed the css selectors automatically at random times the script in my extension would be void after a while… this same approach could be used to steal credit card info and passwords by having a dictionary of common css selectors for these fields… obfuscation would make this harder
-
I know how this could be achieved by making a few changes to quasar, i could’ve forked it and do it but I want to check if its built in since so far everything else I needed seemed to have been built into quasar.
-
No. There is no CSS obfuscation in Quasar.
Scott
-
@chey if you manage to have your extension installed than you can obviously do what you want, no level of client code protection will totally/absolutely/everytime protect said code.
if you want to use extension, I assume you need to obfuscate/hide this code, too. Fortunately, such extensions are prohibited- see here - obfuscated code not allowed:
https://blog.chromium.org/2018/10/trustworthy-chrome-extensions-by-default.htmlI consider your objections - in this specific context of course - as moot.
The question is, would it be to have a possible context, where obfuscation of client code would give greater security? Well, the practice and experience dictates, that such an effect is opposite in terms of security. Why? Because it gives people false sense of security. How? You know, that technically it is just not possible to protect client code from malicious use/reading/analyzing etc. So when you even slightly convince user, that there are even little security measuers independent from user actions, he will eventually make something which truly expose him to vulnerability. It is a user decision if he/she will allow to expose some specific functionalities (in example access to microphone) in specific context (this html page) and only at this specific time and place. If this decision is made, than it is a browser/os/network responsibility to not allow leaking data in those realms. For example if user allows use of his microphone, than she should be sure, that is is only one, specific microphone and not camera also, if she allows to use that microphone on specific html page, then browser should not allow to access this microphone from another tab, and the most important, if this data is transmitted to specific server, no man in the middle, be it another os process or router or anything, should be able to intercept those data. As you can see, obfuscation, in terms of security defined in above terms, is of no practical use.
-
The only reason you might want to hash css classes is to make the final bundle size the user gets smaller. And unless you are building some large app like Facebook or Googlemail, your gains will be minimal. Why waste time with something practically worthless, when you can be using that time to build something great, and if it does get big, you can worry about css size and obfuscation at that time?
Scott
-
Hi @s-molinari , checking back to see if you decided that obfuscation is worthy of your help
-
Sorry, I’m not the one to help you on this.
Scott
-
@s-molinari is there anyone you would recommend that I check with?
-
Not that I know of. Everyone I know, I believe, thinks like I do, that obfuscating code isn’t anything that is useful towards security. And, you most definitely don’t have a Facebook or Google Mail like application, so the benefits of smaller packages through obfuscation won’t be realized either. So, it’s a waste of time to chase a non-existent concern.
Scott
-
@s-molinari The 2 applications I’m working will need the class names to be smaller anyway, so even though I accept that client-side security methods like this wont really protect anything I’ll still need the obfuscation because one is an integrated form and document management platform and the other is a platform to handle communication from multiple sources from emails to site chats to Instagram DMs to Facebook comments and even SMS so I dont believe its fair to assume I dont a codebase that’s as big as a platform like Facebook or Google Mail just because I’m currently a “nobody”, I just didnt know how to word what I wanted properly and that the chrome extension incident in high school was a simple way to explain “systematic” renaming of classes to something different from whats in the source files.
-
This might help you on your way. https://medium.com/@my_own_grave/reducing-css-generated-by-vue-loader-by-using-classnames-shorten-trick-aa1d25d77473
Scott
-
That medium title tho haha, read the link about css modules, looks pretty neat. Will use that for sure, since scoped seem limited afaik.
-
What’s wrong with the title? @metalsadman
Scott
-
@s-molinari ah no i was wrong, notice it’s the author’s username.
-
Ah. Ok. Hehehe… my_own_grave. Yeah. That’s a riot.
Scott
-
@s-molinari would you agree that there should be a property of build in quasar.conf.js called obfuscate where when a “salt” for the “hash” is placed the JavaScript and CSS of the project is obfuscated when built? If you agree I’d be happy to work on it.
