When I started with a tech docs, I bumped into a naming issue. What part of the ecosystem I'm actually writing it for? So let's dive into that and make clear what's what.
QetriX is an ideological foundation (framework, paradigm, manifesto...), saying we have a Page with a unique path, that loads Modules, that use Components, Services and Converters. It defines principles, coding standards and file structure. There's no particular intention and you can implement any kind of software in it – apps, games, tools, firmwares etc.
QetriX itself represents no source code, but there are several implementations in different languages and platforms. All the official implementations are open source and available on GitHub.
Qedy is an implementation of QetriX, that defines particular way of defining modules using JSON and is tailored for web apps. You can consider it as an extension of QetriX, but in reality it sits on top of it.
Qedy introduces Objects, Elems and Features, also handles items, actions, conditions and other aspects, that makes development so easy.
Qedy has been already created for C#, JavaScript and PHP and is the source code available under a commercial license.
Quid is not a software platform, but rather a set of predefined Qedy modules (UI, data structure...), based on the customized QuidModule class. Thanks to the layout layer and its visual editor, it's very easy to customize modules for different customers.
You can order Quid for your home or company today from the Quid Store.
So because I was writing a tech doc, I was actually describing all three, although first two only in the first chapter. The rest of the docs is describing particular modules, that are created specifically for Quid.
User docs is a different thing, that would be solely for Quid, because Qedy and QetriX are under the hood and doesn't concern neither end user or superuser/admin.
I was asked to do a security checkup of customer's web systems. They have a website, an intranet system and they use Google Workspace. I'm no security expert, so I'm reluctant to call it an “audit”, also because there wasn't virtually any budget for it, including penetration or security tests.
It was quite fun, because it was different from what I usually do. What was less fun was what I found during the process, like broadcasting running on ancient PHP 5.4 on Debian 7 in a server signature, exposed database administration, too specific error messages, too many opened ports, self-signed certificates, no security headers, loading two heavy Facebook iframes with only one visible on a landing page and other stuff like that.
When I finished, the report had 18 pages. Let me share with you a generic introduction for the management:
With the significant increase in the popularity of web technologies not only for websites, but also for applications and information systems in the past 10 years, web security has become a large and highly specialized industry.
A possible attack on a web system can be carried out in many different ways on many different types of components. With the exception of the application itself, it can be an attack on its admin section, on application or database server software, eavesdropping on data send between the server and the user or an attempt to lure access data from the users themselves.
The main weapons in the fight against attacks become the use of:
Another great weapon is the responsible behavior of the users themselves. The web system can be more secure, but if attackers manage to lure access from a trusted user data will gain access to the system anyway. An example is the social network security incident Twitter from July 2020, when the attackers took control of the accounts of several important personalities after the acquisition access to internal management tools.
Manufacturers of modern web browsers largely hide ignorance or laziness authors of web presentations or applications and implement a number of security features that vary types of attacks make it difficult or even impossible.
This is most evident in the promotion of a secure HTTPS connection using SSL certificates, which is currently considered the standard due to these efforts. Communication between the browser and the server takes place in text form, so it is possible for an unsecured connection, use a network communication analysis tool to determine transmitted content - including, for example, sent passwords when logging in.
However, encrypted communication cannot be intercepted in this way, and in addition, it makes the type of attack significantly more difficult "Man-in-the-middle", where an attacker forces a user or computer / phone to connect to a server through its device (which is typically a laptop or battery-powered single-board computer, network visible to other devices as free Wi-Fi in a public place) and then able to not only eavesdrop on the communication, but also change it.
This is, after all, the reason why it is appropriate to check in public whether its operator It actually provides free internet access and what the exact name of an official Wi-Fi is.
But under certain circumstances, that may not be enough, because the attacker has the option of his fake network name visually similarly, e.g., use zero instead of “o”, or lowercase “L” instead of “i” and “AIRPORT WIFI” will be “AIRP0RT WIFl” (i.e., “airp0rt wifl”), which can be practically imperceptible.
However, many other security aspects require browser manufacturers to go web developers and administrators, so to speak, opposite, for example by adding so-called response headers server, which can be imagined as a set of communication parameters. Headers are standard part of the Internet communication and are sent both from the browser to the server for each request, so from the server to the browser for each response. These headers can, for example, instruct the browser not to communicate with foreign servers outside of the listed, or to communicate exclusively over the secure HTTPS protocol.
A separate chapter is attacks directed at the database. Because the vast majority of data entered into various web forms (login, search, comments) is further processed using a database, an attacker can add such database to the data entered commands that, in an untreated application, first cancel the execution of the original commands and replace them the database executes the attacker's commands.
These types of attacks are notoriously large and large among developers and authors of database programs some databases and programming languages already contain the necessary protection "from the factory" and apply it automatically.
This issue can occur if the authors of web applications and presentations use outdated ones ways to work with the database, when it was easy to forget about the manual treatment of user input or do not include all validations.
It can also be a problem if they use built-in functions to treat inputs, but in an outdated version that contains a known vulnerability and, under certain circumstances, to an attacker allows you to send untreated content to the database anyway.
Web application security is monitored by the Open Web Application Security Project (OWASP) and the community around it. As of 2017, the following "Top 10" security threats apply:
1. Database attack (Injection);
2. Unreliable user authentication;
3. Leakage of sensitive data;
4. Untreated processing of XML files (XML External Entities, XXE);
5. Non-functional access control (Access Control);
6. Incorrectly configured security;
7. Cross-Site Scripting (XSS);
8. Unsecured deserialization of objects;
9. Use of components with known vulnerabilities;
10. Insufficient logging and monitoring.