DEV Community: Kah

Never trust an upload's filename

Kah — Sat, 22 May 2021 09:25:21 +0000

It's generally accepted that we should never simply trust a user's input. Otherwise, we're vulnerable to malicious input (CE-5). For a file upload from a user, it’s common to check their file size or type, especially when restricting them by those two attributes. But one that might get overlooked is the filename.

Checking the filename is especially important when it displayed on a web page to prevent HTML or XSS injection. That’s just on the frontend. On the backend, there are the other usual injections to worry about. Like SQL injection, when storing the name in a database. Or path injection, if storing in a path based on the name.

It might be tempting to dismiss this possibility as something that would never happen. After all, we must make the files first before we can upload them and there are file-naming rules. We can't simply make one with just any name they want! However, the rules won’t prevent malicious filenames!

OS file naming rules won't prevent injection

Operating systems have rules about what can be in a filename. But, different operating systems can have different rules. So, a filename prohibited in one operating system may be allowed in another.

For example, <img onerror="alert('XSS')" src="nowhere">.txt. The file can't be created in Windows because it doesn't allow < and > (see Naming a file). However, Linux does allow them. For example, we could use touch to create the file:

touch '<img onerror="alert('"'XSS'"')" src="nowhere">.txt'

Actually, we don't even need to make the files

HTTP clients usually send file uploads using a multi-part POST request. We can use Wireshark to see what the request looks like. Here's one from cURL:

POST /attachments HTTP/1.1
Host: 127.0.0.1:3000
User-Agent: curl/7.76.1
Accept: */*
Content-Length: 250
Content-Type: multipart/form-data; boundary=------------------------6c44be865e1d13e6

--------------------------6c44be865e1d13e6
Content-Disposition: form-data; name="attachment"; filename="Lorem_Ipsum.txt"
Content-Type: text/plain

Lorem ipsum dolor sit amet, consectetur cras amet. 
--------------------------6c44be865e1d13e6--

Notice the filename field is at the end of the Content-Disposition header. We can use this as a template to make our own requests. Simply. copy and paste into a file, change the filename and update the Content-Length. Then use Ncat to send the request. For example, to send the request in request.http to http://localhost:3000:

ncat localhost 3000 < request.http

Using HTTPS isn't enough either

The example above sent a forged request to an insecure server (i.e one that isn't using SSL/TLS). But changing over to HTTPS still won't be enough to prevent malicious filenames - Ncat also works with HTTPS connections:

 ncat -C --ssl localhost 3000 < request.http

Even if it didn't, it we could go back to using a web browser to upload files over HTTPS.

Pentesting tools makes this easier

Using Wireshark and Ncat was how I first learnt to do this. It turns out pentesting tools like mitmproxy make this easier - it can intercept and modify the requests in-flight.

Burp Suite's proxy has similar features.

Prevent injection via filenames

There is just no way to guarantee a server never receiving an upload with a bad filename. The server must guard against it - usually by sanitising or encoding and escaping where it is used (OWASP CE-4). Doing so will help to prevent injection attacks via filenames.

Why 3 > 2 > 1 gives false

Kah — Fri, 11 Sep 2020 23:36:53 +0000

Recently, I saw this question about how does Javascript evaluate an expression:

gwagsi glenn

@gwagsig

why is
console.log(1<2<3) ;
true
and
console.log(3>2>1) ;
fasle
?
#100DaysOfCode #CodeNewbies #javascript

08:58 AM - 10 Sep 2020

So, why does 1 < 2 < 3 give true, but 3 > 2 > 1 give false? According to operator precedence and associativity, they are evaluated from left to right. So...

1 < 2 < 3 is evaluated as (1 < 2) < 3.
1 < 2 is true, making the expression true < 3.
How does it compare a true against a number? It does this by first converting the boolean to a number. true is converted to 1 and false is converted to 0 (see 7.1.14 of the ECMAScript specififcation). Thus, the expression is evaluated as 1 < 3 which gives true.

Now for 3 > 2 > 1:

Going left to right, 3 > 2 is evaluated first which is true. The expression becomes true > 1.
To evaluate, true is converted to 1. This gives 1 > 1, which is false!

For bonus points, try figuring out 1 < 3 > 2 and 1 > 3 < 2 gives.
Answers:
For 1 < 3 > 2:

1 < 3 is true, so it becomes true > 2.
true is converted to 1, so it becomes 1 > 2, which is false.

For 1 > 3 < 2:

1 > 3 is false, so it becomes false < 2.
false is converted to 0, so it becomes 0 < 2, which is true.

Python's with/for...else and try...else

Kah — Sun, 09 Aug 2020 13:32:38 +0000

In most programming languages like C, Java and Javscript, the else clause is used with if statements. But did you know in Python the while and for loops as well as the try statement can also have else clauses?

In the `while` loop

To get a sense of how the else works with the loops, it's easy to write some code to play with. Here's the first one I tried:

basket = ["apple", "orange", "pear", "banana"]
i = 0
while basket[i] != "apple":
  print(f"Its not {i}")
  i = i + 1
else:
  print("Else block ran!")

print(f"i is now {i}")

What do you think will be the output? At first, I thought it would output Else block ran! followed by i is now 0 (i.e. it would execute the else block) because the first item in the list is already apple. The output certainly shows this happens:

Else block ran!
i is now 0

But, what if we changed the condition in the while loop to basket[i] != "banana"? The body of the while loop should now run, so I first thought it would surely skip the else clause ...

Its not 0
Its not 1
Its not 2
Else block ran!
i is now 3

Nope! It printed Else block ran!, so the else block must've ran!

So what's going on here? Turning to the documentation on the while statement:

This repeatedly tests the expression and, if it is true, executes the first suite; if the expression is false (which may be the first time it is tested) the suite of the else clause, if present, is executed and the loop terminates.

A break statement executed in the first suite terminates the loop without executing the else clause’s suite.

So, if we want to skip the else block, loop needs to exit with a break.

Rewriting the while loop to use break to exit when it finds a match:

basket = ["apple", "orange", "pear", "banana"]
i = 0
while i < len(basket):
  if basket[i] == "banana":
    # We found what we were looking for.
    break
  print(f"Its not {i}")
  i = i + 1
else:
  # We couldn't find it in the list.
  print("Else block ran!")

print(f"i is now {i}")

The output now doesn't contain the print in the else block:

Its not 0
Its not 1
Its not 2
i is now 3

And just to check, setting the if condition back to basket[i] == "apple" also doesn't run the else block:

i is now 0

In the `for` loop

The behaviour of the else clause in the for loop is the same as that of the while loop. Rewriting the while loop to use for instead:

basket = ["apple", "orange", "pear", "banana"]
find = "banana"
for f in basket:
  if f == find:
    print(f"We found {find}!")
    break;
else:
  print(f"There isn't any {find}!")

Running this, you'll get the output We found banana!, but changing find to "grape" will result in There isn't any grape!.

In `try` statements

For the else in try statements, the documentation states:

The optional else clause is executed if the control flow leaves the try suite, no exception was raised, and no return, continue, or break statement was executed. Exceptions in the else clause are not handled by the preceding except clauses.

Here's an example of a try with an else clause:

try:
  # This will raise an AssertionError
  assert 1 == 2
except:
  # Catch all exceptions
  print("Got exception")
else:
  print("Else!")
finally:
  # Finally always runs at the end
  print("Finally!")

With the AssertionError thrown, it skips the else. This is the output:

Got exception
Finally!

But changing the assertion to pass (e.g. assertion 1 == 1), no exception is thrown and, thus, else is executed:

Else!
Finally!

However, you could do the same thing without an else clause - anything within the try block after the line that can throw the exception is effectively the "else". For example:

try:
  # If this assertion fails, this will throw an AssertionError
  assert 1 == 1

  # No exception thrown, so everything here is the "else"
  print("Else!")
except:
  # Catch all exceptions
  print("Got exception")
finally:
  # Finally always runs at the end
  print("Finally!")

So given this alternative, apart from style, why would you use the else clause? The difference is in when the else block throws an exception (thanks to this Stackoverflow answer for pointing it out). If it's part of the try block, the exception may be handled by one of the try's except handlers, but it's passed up the chain if it's in an else clause - none of the handlers defined in the same try statement will handle exceptions from the else.

To see this, let's modify the try statement so that the assert becomes the else. First, without the separate else clause:

try:
  # Body of try. Won't throw an exception. 
  print("Try body")

  # The "else" part. Make it throw an exception.
  assert 1 == 2
except:
  # Catch all exceptions
  print("Got exception")
finally:
  # Finally always runs at the end
  print("Finally!")

The output for this is:

Try body
Got exception
Finally!

Notice the except block handled the exception from our "else". So to check that using the else clause doesn't trigger one of the handlers:

try:
  # Body of try
  print("Try body")
except:
  # Catch all exceptions
  print("Got exception")
else:
  # Make else thrown an exception
  assert 1 == 2
finally:
  # Finally always runs at the end
  print("Finally!")

Which gives the following output:

Try body
Finally!
Traceback (most recent call last):
  File "main.py", line 9, in <module>
    assert 1 == 2
AssertionError

What's in a useful commit message?

Kah — Sun, 26 Jul 2020 00:53:13 +0000

When making a commit, Git prompts you to enter a message to store with the commit. Commit messages are messages for someone looking at the change in the future. They can help them in making sense of the changes, but Git can't enforce that you write a useful one - how can it? Instead, it is up to you to write something useful for them. So, what can you write to in a commit message to make it useful?

No matter who is looking at the commit message, it helps to describe what is in the commit. This is most likely the first thing anyone will want to know about a commit - what is this commit about? The git commit documentation recommends this being the first thing in commit message:

Though not required, it’s a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. The text up to the first blank line in a commit message is treated as the commit title, and that title is used throughout Git.

Visually, the format looks something like this:

commit title (less than 50 characters recommended)

more thorough description

Log viewers like gitk display their title in the list of commits.

A descriptive title describing what is in the commit will make the logs much more easier to work with.

If you're finding it difficult to write a descriptive title for the commit, perhaps have a look what is in the change and see whether the commit is trying to do more than one thing. Ideally, the commit should be doing just one thing.

When looking back to a previous change, a very common question that is asked is why did we make that change? When trying to build changes on top of previous changes or trying to fix an issue in code, knowing why the changes were made in the first place can help avoiding introducing more problems later. For contributions to other projects, it helps to convince maintainers that they should be included. For your future self, it can help to serve as a reminder of why you did what you did at the time. An explanation of the why indicates that the changes were thought out and wasn't just done on a whim.

Sometimes, the why is implied in the title. For example, "fix spelling errors" would likely be self explanatory. When its not, this is something that should be written in the commit description. Describing the why could also include answering:

If the change fixes something, what was wrong in the first place? Were there any lessons learnt?
If it is an new feature, what does it do?
If it is an optimisation or improvement, how does it improve things? Are you also able to quantify the improvement?

When Git prompts your for a commit message it may be tempting to just fill this in with something to fulfil this step, but to do so would be squandering an opportunity to capture valuable information about it. Writing one is about spending the time and effort now to help someone in the future - it can be immensely helpful in understanding your change and its purpose. Someone may thank you for it one day!