35

Using eval in this context doesn't create any vulnerability, as long as an attacker can't interfere with the arguments passed to matchCondition. If you find it easier to read / program it this way, and you're confident that no untrusted input will ever go into your expression compiler, then go for it. eval isn't evil, untrusted data is. Please note that ...


31

Today, everything is written by developers. Next month or next year, someone will say "hey, why not let the users write those themselves?" Bam. Also, even if the rules are written by the developers only, do they or will they include any user-originated data? Something like titles, names, categories, for instance? This could quickly lead to an XSS attack. ...


5

Appearances and expectations If something looks like a safe expression, people will probably treat it like one. If a field looks like any other data-field, people (even developers) will probably put untrusted data in there. If something is evaluated with full level application access, it should look and feel like code. Another problem are subtle bugs in ...


3

Front-end javascript itself is completely at the will of the client running the code. If you are depending on front-end javascript for security, you've already failed to secure your application. Forget eval. The client can replace your entire website with their own implementation if they desire. Thus, your server should validate everything that the ...


3

To avoid many attacks, you should pay attention to what type of content you're manipulating. What looks like text is not necessarily text. This applies both for SQL (SQL Injection) and HTML (XSS). The string abc is written abc as text. It is also written abc as HTML. So you may think that if you have text to display, you can just concatenate it with the ...


3

In true end-to-end encryption you'd generate keys for authentication on the client. The actual encryption is usually done using an algorithm which supports forward secrecy, like Diffie-Hellmann. The web is a bad form factor for this, as local storage can usually be deleted at any time. As for your last question: there is an implementation of the Signal ...


1

If we use an external JS file and just link to the file from the HTML using tag, will the issue still be reported? It depends (it always does). When you would do it the way as described below, it most likely will: <script src="https://external.party.com/mylibrary.js"></script> The reason is you have no control over the library that is loaded ...


1

You seem to have a decent grasp of it. Anything that can redirect the user via a POST request can be used to exploit - this is often done via an HTML form but is by no means the only way it can be done. As you mentioned various javascript functions can also redirect the user. The most significant difference between POST XSS and GET XSS is how you phish the ...


1

That's correct: if you want to exploit a POST-based XSS, you need the user to do a POST request with malicious to the exploited page. This is most often done by adding a auto-submitting form in a HTML page hosted by the attacker. There are other techniques, like clickjacking, but hosting a HTML page is the easiest way to go. Using the Fetch API isn't ...


1

As others have said, as long as your rules really are coming only from trusted developers, there shouldn't be any security holes from using eval. However, eval has plenty of other disadvantages, in terms of complexity, maintainability, debuggability, etc. And using regular expressions plus eval could easily result in problems down the road, depending on how ...


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