Switching to Web

[Otto]

Hello friends,

I would like to ask for your support.

It is becoming increasingly clear that the future is moving towards web servers and web-based solutions. We are also about to release our online version, which will then require a server.

**Risk Assessment for the Web Server**

**Status quo**
Currently, no web server is installed, which means there is no attack surface for web-based threats. In its current configuration, the server is only at risk from general network and system vulnerabilities. No external access via web protocols (HTTP/HTTPS) is possible, so the attack surface is limited to existing services and their security configurations.

**Risks after installing a web server**
Installing a web server introduces a new attack surface, which presents the following risks:

**Increased attack surface:** A web server makes the server accessible from the outside, increasing the risk of attacks, including:

- Brute-force attacks on login pages.
- DDoS attacks (Distributed Denial of Service) that can overload the web server.
- Vulnerabilities in web applications (e.g., PHP scripts) that could be exploited through SQL injections or cross-site scripting (XSS).
- Man-in-the-middle attacks on unencrypted HTTP connections (Port 80).

**No SQL server and no HTML requests:** Since no SQL server is installed, SQL-specific threats such as SQL injections are eliminated. Additionally, direct HTML requests are not supported, meaning the application is entirely PHP-based.

**Risk from unencrypted connections:** If Port 80 (HTTP) is used, there is a risk that sensitive data may be transmitted in plain text. However, our system exclusively uses HTTPS (Port 443) to minimize this risk.

**Outdated software:** If the web server or PHP is not regularly updated, security vulnerabilities can arise, which can be exploited by attackers.

**Lack of access control:** Insufficient file permissions can lead to unauthorized access to sensitive files.

**Incorrect firewall settings:** Opening ports for the web server (e.g., Port 443 for HTTPS) poses a risk that unwanted traffic could enter the network if the firewall is not properly configured.

**Recommended countermeasures:**

- **Use HTTPS (Port 443):** Exclusive use of encrypted connections with an SSL/TLS certificate minimizes the risk of eavesdropping and man-in-the-middle attacks.
- **IP address restriction:** Restrict access to the web server to known, authorized IP addresses to prevent unauthorized access.
- [ in our case: Secure configuration: No SQL databases will be installed, and the application will run only on PRG/PHP. HTML requests will not be supported, reducing the risk from insecure web requests.]
- **Automatic security updates:** The web server should be configured to perform regular updates to close known security vulnerabilities.
- **Firewall optimization:** Only the necessary ports (e.g., Port 443) should be opened to prevent unwanted traffic.
- **Intrusion Detection System (optional):** An IDS can monitor the web server for suspicious activities and attempted attacks to detect threats early.

Two-factor authentication is also a priority for Winhotel access. While someone can easily share their password, giving away their phone is a bigger hurdle.

[vilian]

Hi Otto,

The company who provide internet to us implement treatment to the majority of the situation you have listed. They only recommend we don't use Mysql default port(3306) and also blocking the user ROOT for external access. We have our own server for years

[Otto]

Hello friends,
This might be a bit off-topic, but you never know. Since ADS is no longer sold or supported, it could potentially cause issues with a future Windows update. I think it's always good to start looking around in advance.

Currently, I'm experimenting with low-level access to DBF. It's actually working surprisingly well. I have a test browser here where I can easily open various DBF files and try out a few things.

It's a simple customer file with around 200,000 records. Since I see my future in the web, I want to initially manage without indexes. When I create a temporary index on a column, for example, it takes about 500 ms. Then, paging from one page to another takes about 25 ms.

For me, 200,000 records is already a large database.

I then did the same test with 1,200,000 records. In this case, it took about 3 seconds for 87,228 matching records to be sorted.

*** Data fetched: {elapsed_time: '3087.3920917511 ms', last_index: 1199964, records: Array(20), indexes: Array(87228)}

There's no noticeable difference when paging, it's still under 25 ms.

Bestregards,
Otto