If possible I would like to have clish to rewrite any arguments that are not safe to inject in an sql query. Similar to doing for example mysql_real_escape_string in php.
From clish we are calling bashscripts that sometimes injects the arguments into sql queries. Offcourse we should check/rewrite the argument in the bash-script's, but making clish rewrite the query would be an extra security in case that are missed/forgotten.
I have made a wrapper that executes all clish commands.
It will look like this in the command xml syntax:
<ACTION>execWrap aCommandToExecute ${someArgument}</ACTION>
execWrap will execute "aCommandToExecute" with all folowing arguments passed to it after verifying that the arguments are safe.
However, I will not mark the question as solved as it would be prefered to do this inside clish.
Related
In powershell
$a = 4;
$a
will write 4 to the output stream.
Write-Ouput $a
writes 4 to output stream
Can you explain which operation is better performance wise if all I want to do is write variables to output stream?
If you just want to see what's in your variable, you should use a dollar sign with the name of your variable. This is most likely the fastest method to display the value of the variable.
UPDATE
Short answer: You should use just $a in order to write data in the output stream. It's the fastest way to do that.
Long answer with explanation:
If you write something like $a, then it goes directly to the output stream of the current PowerShell process, in other words, it goes to the output pipeline. This is because in PowerShell you have in general only three types of possible statements:
Definition statement: They are everything that you can define in your code for further use like functions or classes.
Assignment statement: You assign a value to a variable.
Putting-in-the-pipeline statement: everything else except 1 and 2.
Example for definition statements:
Function foo($bar)
{
#do stuff here
}
Example for assignment statements:
$foo = 'bar'
Example for putting-in-the-pipeline statement:
It is exactly what you asked! If you write $a, then it will be written to the output pipeline. That’s it.
Now about Write-Output. According to this code from the official PowerShell repository, it's just a wrapper for another PowerShell Cmdlet, namely for WriteObject. Therefore, the invocation of Write-Output costs more time then the invocation of WriteObject.
As Lee_Dailey mentioned in the first comment to your question, there is a wonderful article Let’s Kill Write-Output written by Mark Kraus in his blog. At first sight it may seem that it doesn't have much to do with your question, but this article explains what happens with objects that you wrote in your script and when they are not surrounded with different "printing functions" like Write-Out. There you can also find examples of how to "bypass" the use of the Write-Out in different situations that it brings advantages in performance.
I also recommend to read these two articles from Microsoft's DevBlogs:
Understanding Streams, Redirection, and Write-Host in PowerShell
Weekend Scripter: Welcome to the PowerShell Information Stream
They will definitely help to understand how streams are implemented and how they work in PowerShell.
If I have this command:
do_something
And requires 2 arguments argument_1 argument_2
argument_1 can be anything
argument_2 only can be true or false
A non-required third argument can be added argument_3
What is the standard to describe a script calling template?
I remember to have read somewhere about the different meanings of <> and [] and {}. For example:
<> mean required
[] mean non-required
{} contains a list of possible values
So for my example it will be
do_someting <argument_1> {true,false} [argument_3]
But I don't find any place that is confirming this syntax.
I would write the following:
do_someting argument_1 {true|false} [argument_3]
I think mendatory arguments don't need any kind of braces, it looks clearer like that. Furthermore, the pipe feels more standard to represent an "or" statement.
I am not aware of such standard, but you can have a look at Google recommendations or docopt for example. Also, here is a POSIX document which may interest you.
The conditional construct of if command looks like this:
if TEST-COMMANDS; then
CONSEQUENT-COMMANDS;
[elif MORE-TEST-COMMANDS; then
MORE-CONSEQUENTS;]
[else ALTERNATE-CONSEQUENTS;]
fi
And the loop construct of while command looks like this:
while TEST-COMMANDS; do CONSEQUENT-COMMANDS; done
I was wondering why then is needed in if command but not in while command? Why couldn't it be ommited?
do in the while syntax serves a similar purpose to then in the if syntax. They both signify the start of the body of the statement - differentiating it from the condition part of the statement.
The if conditional statement is a compound statement in the shell. The if & then sections of the statement are executed as two parts, the then section is only invoked if the if section ends with an exit status of 0. Both sections may contain multiple statements; therefore, a semi-colon alone is insufficient to separate these sections.
Like #shibley is saying in his answer, the do and then words are used to indicate the beginning of the block of actions to perform.
I have done some research and could not find the historical reasons, so I am going to guess the logical ones. It might be too subjective, so do not hesitate to comment your impressions below.
The bash syntax is quite "symmetrical": Whenever you have an case you finish it with esac. Also, it was designed in a very human way, so it is easily understandable.
That said, if you are in a while loop, it means that you are going to do something while a condition is true. Then, when it is not true anymore you are done.
However, in an if condition, you are saying that if something happens, then something needs to be executed.
In short: do and then are human-readable ways to indicate the same, that is, the beginning of a block of commands to be performed upon a while or if condition.
I have a groovy DSL script like this:
entity(attribute1:"one", attribute2:"two")
so far so good. I run the script and set the script's delegate to a class where entity's defined, and the class handles everything.
Now I want to do this:
entity(attibute1:(subattribute1:"one", subattribute2:"two"))
Is this somehow syntactically possible? Since (subattribute1:"one", subattribute2:"two") itself doesn't mean anything, I'm assuming not, though I'm wondering if there are some Groovy magic that I'm not aware of that allows this.
And I don't want to do
entity(attibute1:[subattribute1:"one", subattribute2:"two"])
even though I know that works. Just a syntax preference.
No, you have to use the square brace (as you have said you don't want).
The first example:
entity(attribute1:"one", attribute2:"two")
is a shortcut for actually calling:
entity( [ attribute1:"one", attribute2:"two" ] )
So, you would either need the square braces, (to signify the attribute1 key contains a map, or you would need to prefix the brace with another method name such as:
entity(attibute1:attribute(subattribute1:"one", subattribute2:"two"))
I am doing a security test on a system having an embedded TCL interpreter. The system receives input from the Internet (HTTP), parses it and passes to customisable TCL scripts. During a fuzzing test (sending binary garbage in HTTP headers) I have noticed the following errors in the log:
TCL error: list element in quotes followed by "{}x" instead of space while executing "foreach header [ XXXXX ] { }"
or
TCL error: unmatched open quote in list while executing "foreach header [ XXXXX ] {}"
Here XXXXX is a command returning an array of HTTP headers, as parsed by the system. Sorry for obfuscating the real command, I hope you understand I don't want to make too many details public before the vendor is informed about the issue (if it turns out to be an issue).
TCL code producing the error is very simple:
foreach header [ XXXXX ] { }
As far as I can tell, HTTP parsing is done outside of TCL and parsed values made accessible to TCL via custom commands (possibly implemented as TCL extension).
So my questions are:
Are these error tell-tale signs of security problems with the system, such as insufficient user input validation?
If yes, can this condition be exploited to execute arbitrary TCL statements by sending the system specially crafted request, a kind of code injection attack?
Are there any "Secure TCL coding practices" document? I could not find any.
You asked this on comp.lang.tcl where I replied with:
1) Are these error tell-tale signs of security problems with the
system, such as insufficient user input validation?
They're an indication of problems in the parsing code. I'd guess that
the code is assuming that it can assume that a header is a well-formed
Tcl list, which you've found to be wholly unsafe. Sanitization is to
use something like this:
set listOfWords [regexp -all -inline {\S+} $someString]
The resulting collection of words is guaranteed to be a well-formed
list, for an arbitrary input string.
2) If yes, can this condition be exploited to execute arbitrary TCL
statements by sending the system specially crafted request, a kind of
http://en.wikipedia.org/wiki/Code_injection attack?
Probably not, not unless you then treat that list as code.
3) Are there any "Secure TCL coding practices" document? Any other
source of information on how to safely handle untrusted data?
The simplest method is to do the parsing in a Safe Interpreter:
interp create -safe parsingInterp
parsingInterp eval { make the procedures }
parsingInterp eval [list doTheParse $stringToParse]
Note that we also guarantee that constructed lists (e.g., those out of
list, and many other commands besides) are eval-safe. That is:
eval [list $a $b $c]
is exactly the same as:
$a $b $c
This is true whatever is in those variables.