-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Most patterns that include constant strings are treated as 'INVALID' #66
Comments
It looks as if a change was recently made to the server code and only previously evaluated patterns are returned correctly now. Everything else is treated as INVALID. |
That's a bit surprising because I don't believe I deployed the recent pushes to the server. But I will take a look. Thanks! This might instead be due to certificate + the local cache, depending on how you're using the system. Are you using the vuln-regex-detector npm module? |
Answer to your earlier question (it took me a while to understand what you're driving at): Yes, we are using the npm module. Here is an extract of the program: const cacheConfig = { process.env["NODE_TLS_REJECT_UNAUTHORIZED"] = 0; // Server certificate has expired! No idea whether that means we are using the "local cache" or not. Since I last tried it nearly a week ago, my MacBook Pro has been restarted several times. Now I find that ALL patterns are returned as INVALID. What can I do to reset or disable the cache? |
I'm running this under MacOS X and it seemed to work fine to start with. But I didn't run the configure command - and now that I have tried (in order to fix the hypothetical caching problem) I discover that it cannot be run other than under Ubuntu Linux! Is it actually necessary to run the configure command if I'm only trying to use the client? NB I found the default cache configuration in vuln-regex-detector-client.js and set it to CACHE_TYPE:none (both in the vuln-regex-detector project, which is what VULN_REGEX_DETECTOR_ROOT points to, and in the node_modules folder of the project I'm trying to scan. It still reports INVALID for every pattern, and in fact the cache folder is empty. |
Nope. You just need to point the module at an appropriate endpoint (e.g. the one I have deployed at Virginia Tech, or one you manage internally if you're uncomfortable sending regexes to outsiders).
OK.
It should not be doing this. My deadlines wrap up today so I will be able to triage shortly. |
For example:
"^\d+": SAFE
"^\d+:": INVALID
"^\d+z": INVALID
"(a+)+$": VULNERABLE
"(b+)+$": INVALID
"x": INVALID
The text was updated successfully, but these errors were encountered: