![Why Do Web Applications Need to be Secure? 11
A few years ago, there was a Dutch company in the business of providing
digital certificates, most notably used by the HTTPS protocol for encrypting
traffic between browsers and web servers.
The HTTPS protocol, as we will see in section 3.4, uses two keys: a public
key (the digital certificate) and a private key, which must be kept secret. The
public key is signed by a certificate authority: if this authority accidentally
reveals the private key used to sign certificates, anybody can generate them,
and website owners can no longer be reliably authenticated.
This company was targeted by a cyber-attack, and its root certificate (the
private key) was stolen: the hackers were therefore able to generate as many
certificates as they wanted, allowing them to easily intercept traffic and
generate false certificates to mislead users.
The root certificate was very quickly revoked and deleted from users’
browsers. Consequently, all other certificates that it had been used to generate
were also revoked. The company had to declare bankruptcy [WIK 15c]: the
cyber-attack led to its ruin.
Not every example is this serious, but the consequences can nevertheless
be significant. It shows that the risks must be taken into consideration from the
earliest stages of the project.
In recent years, shop cash registers have been automated, i.e. operated by
a remote server. Imagine what would happen if the computer system fails on
the Saturday afternoon before Christmas: it would not be possible to record
any payments. Clearly, this risk must be considered by the analysis: the loss of
revenue would largely cover the costs of implementing a backup solution.
In a similar spirit, many companies save credit card numbers – not just
banks, but also large Internet-based traders, such as Amazon and Google.
Although there are many advantages for companies in having the card
payment information of their customers (purchasing is faster and encouraging
more impulsive buying), this requires trust. If a website accidentally reveals
the payment information of its customers, there is a good chance that they
will want to switch providers. Unfortunately, this kind of incident does in fact
happen on a regular basis, even to banks and the companies that issue cards
on their behalf [LEM 14].](https://image.slidesharecdn.com/28026383-250512081332-3330d6d7/85/Safety-Of-Web-Applications-Risks-Encryption-And-Handling-Vulnerabilities-With-Php-Ric-Quinton-23-320.jpg)
![12 Safety of Web Applications
Similarly, if an attacker manages to modify the details of an order, for
example by changing the shipping address of the items ordered by customers
to an arbitrary location, they will be able to cause significant damage, both to
the company’s finances and reputation. It is highly unlikely that a customer
that has been duped in this way will wish to return to the same website to
place another order.
In the same way, we should not make the mistake of believing that
confidential applications are safe from these kinds of attempt.
Imagine a research laboratory that develops an application for data entry.
If this application is poorly designed, it can, in some cases, allow code to be
executed directly on the server that hosts it. If an attacker manages to corrupt
the way that it normally operates, they can infiltrate the server, from where it
is highly likely that they will be able to access the full information system of
the laboratory, allowing them to search for more valuable information.
Just because some access paths are well protected (this is often the case for
network interconnection equipment in the world wide web) it does not mean
that their content is fully inaccessible. A five-meter-high wall is not much use
if a door is accidentally left open, or if it is only secured by a simple latch that
can easily be opened from the inside. Anybody with access to the door can
leave it open: this is what can happen if an attacker manages to take control of
a server or an internal computer system.
Sometimes, the stakes are high enough that attackers are willing to spend
vast resources to penetrate a system. You might, for example, remember the
incident suffered by the Iranian states a few years ago. Iran was attempting to
enrich uranium to produce enough material to make an atomic bomb. This
enrichment was performed by a centrifuge system: since uranium isotopes
have different masses, the centrifuge can separate the minerals by causing the
heavier elements to move outward. A particularly well-designed cyber-attack
[BEN 10] destroyed the centrifuges by making them spin too rapidly. It
probably required months of preparation by exceptionally competent teams.
Experts estimated that this attack set the Iranian nuclear program back by at
least 1 year, which was enough to change the direction of their national policy
and facilitate subsequent negotiations.](https://image.slidesharecdn.com/28026383-250512081332-3330d6d7/85/Safety-Of-Web-Applications-Risks-Encryption-And-Handling-Vulnerabilities-With-Php-Ric-Quinton-24-320.jpg)
![Why Do Web Applications Need to be Secure? 13
Similarly, international politics can change extremely quickly, and a
company or an organization that seems unexposed can very quickly find
themselves in the spotlight, targeted by a coordinated retaliatory attack.
Although there are many different possible vectors for an attack, searching
for flaws in web software is often one of the simplest routes. If an application
is poorly protected and an attacker manages to modify its usual behavior so
that it allows them to install a malicious program on the server, they will be
able to target other components of the company’s information system.
Many security experts no longer ask: Can this system be attacked? but
rather: When will it be attacked? This does not mean that we should give in
to paranoia: the risk should be studied, and there are always ways to make life
difficult for any would-be attackers. But we should remember that no system is
impenetrable, even though some systems are more difficult to beat than others.
1.3.1. Do not take anything for granted
Security is a lesson in modesty: no matter what you do, some clever attacker
will be able to find a way to bypass it. Applications that seemed reliable 10
years ago can be easy to hack today.
Over the last few years, attacks have become increasingly sophisticated. It
is not uncommon for attackers to work for several months to prepare an attack,
devoting substantial human and financial resources to their task. This is far
from the mental image of a brilliant teenager bringing government institutions
to their knees! Of course, the attack needs to be “worthwhile” relative to the
invested resources.
But even with applications that are not highly critical, the risk is never
zero: opportunistic attacks can, for example, be mounted on websites that rely
on a shared framework using newly discovered security vulnerabilities. It is
easy for attackers to exploit these kinds of vulnerability, allowing them to
access valuable information or gain access to other components that
theoretically should have been better protected. For example, many websites
are built with the WordPress publishing engine [WOR 15], one of the most
popular content management systems.
A serious vulnerability was discovered in 2014 [ZDN 14]: all websites
using this engine became vulnerable to attack. As it always takes some time](https://image.slidesharecdn.com/28026383-250512081332-3330d6d7/85/Safety-Of-Web-Applications-Risks-Encryption-And-Handling-Vulnerabilities-With-Php-Ric-Quinton-25-320.jpg)
![Why Do Web Applications Need to be Secure? 15
When I performed the security review of one of my most recent
applications using the documents published by Open Web Application
Security Project (OWASP) [OWA 15a], which we will encounter later), I
found a vulnerability that I was not previously aware of. My application
expected UTF-8 encoding, which could be exploited by certain types of
attack to execute malicious code. The solution is to check that any input data
are indeed encoded with UTF-8 . In fact, there is a simple PHP function that
performs this check. Closing the security gap was as simple as adding 20 or
so lines of code to the beginning of the controller code (see section 4.3.1).
Thus, I was able to protect the entirety of my application against an
unanticipated type of attack simply by modifying a single file, the controller.
1.3.3. The only type of security that matters is global security
Except for smart cards, which are intrinsically secure (their security does
not depend on third-party mechanisms, as we mentioned earlier), a computer
system can only be considered secure if it is implemented within certain
conditions. Imagine an application equipped with the latest state-of-the-art
security measures. If it is deployed on a server that is left completely open, all
of these security measures will be essentially useless: illegitimate access to
the server will allow attackers to circumvent all protective measures.
We will discuss how to implement a certain number of security measures
in web applications, but we will also discuss how the servers themselves must
be configured. This will allow us to define rules that should be applied during
production, and to clarify the general context that needs to be available before
we can consider an application to be reasonably secure relative to the chosen
objectives.
These rules are not a replacement for the work performed by network
architects to properly protect servers and local networks: layers are often
added to make things more difficult for attackers, such as firewalls that block
some types of attack, antiviruses installed on the network equipment and
proxies that allow servers to work through indirect connections to the world
wide web, etc.
Of course, it is rarely the responsibility of the developer to implement these
protective measures. But it may be fruitful to open a dialogue with technical](https://image.slidesharecdn.com/28026383-250512081332-3330d6d7/85/Safety-Of-Web-Applications-Risks-Encryption-And-Handling-Vulnerabilities-With-Php-Ric-Quinton-27-320.jpg)
![16 Safety of Web Applications
teams to discover whether certain checks are already provided by the platform,
to avoid having to include them in the application code. This is especially true
for some aspects that relate to changes in the web server configuration, which
might be performed either globally or application by application.
1.3.4. What security measures are required by applications with
heavy clients?
All too often, people only examine the security of web applications. One
might be tempted to think that applications executed entirely from within a
workstation are unlikely to be attacked from the outside.
However, this is not the case. Applications handle information, and this
information is probably valuable to the company. If a database is used by an
application, and this database runs on the computer, it might potentially be
accessed by other applications. Indeed, by default, local databases are not
password-protected, since they are not accessible from the computer network;
but a malicious program downloaded from a website might also attempt to
access this database. This is in fact a common mechanism for attacking
smartphones.
Furthermore, it is likely the case that the data handled by the PC will be
transferred to the company information system: how is this transfer conducted?
Finally, laptops are easily stolen while traveling. If confidential data are not
properly protected, this can quickly cause problems.
Today, these risks are exacerbated by smartphones, which run all kinds of
applications. Before developing software for this type of platform, good
practice dictates that we should first consult the documents published by
OWASP [OWA 15a], which describe the checks that should be made,
depending on the sensitivity of the application. There are sections dedicated
to these platforms.
Thus, even for applications with heavy clients, it is advisable to conduct a
security assessment, and if necessary to implement the appropriate protective
measures. This is true on every operating system, whether Android, Windows,
Linux or IOS: if a target is considered to be significant in some way, attackers](https://image.slidesharecdn.com/28026383-250512081332-3330d6d7/85/Safety-Of-Web-Applications-Risks-Encryption-And-Handling-Vulnerabilities-With-Php-Ric-Quinton-28-320.jpg)
![20 Safety of Web Applications
Cause
Impact
Probability
Target
Risk
Figure 2.1. Risk
2.2. How can we protect ourselves from risk?
Once the risk has been identified, there are several possible strategies for
preventing it from materializing, or for mitigating its impact. Returning to our
example of mountain driving, there are multiple possible approaches. The
first is to avoid driving in the mountains, and to choose safer roads, which
might, however, increase the length of the voyage. We could also equip the
car with specialized tires (e.g. snow tires in winter), and ensure that all
passengers fasten their seatbelts. Finally, driving carefully, at a controlled
speed, is another way of providing security.
The EBIOS method1 proposes four strategies for managing risks:
avoidance, reduction, transfer or acceptance.
Avoidance consists of selecting an option that renders the event
improbable, for example taking the highway or canceling the trip. In terms of
computer systems, this might correspond to the decision to avoid
computerizing a procedure if the risk for the company is disproportionate to
the expected benefits.
Reduction involves implementing measures to limit either the probability
or the impact of the risk (snow tires, seatbelt, controlled speed, etc.). In
1 There are several global methods for defining the computer security requirements of a
company. In France, two methods are predominantly used (but others exist): MEHARI
[CLU 15a], proposed by CLUSIF, the French Information Security Club [CLU 15b] and
EBIOS [ANS 10], proposed by ANSSI, the National Agency for Information Systems Security
[ANS 15]. These methods restate or comply with the international ISO norms for risk
management [ISO 09, ISO 11, ISO 15].](https://image.slidesharecdn.com/28026383-250512081332-3330d6d7/85/Safety-Of-Web-Applications-Risks-Encryption-And-Handling-Vulnerabilities-With-Php-Ric-Quinton-31-320.jpg)
![Estimating Risk 23
and availability. The criteria are usually graded from 1 to 4, where 1 is the
lowest level of need and 4 is the highest level.
These assessment grids are filled out by the company, which adapts them to
their environment and effective needs. Example grids are of course available;
a few examples are presented below, and others are available from ANSSI
[ANS 10].
2.4.1. Confidentiality
Confidentiality aims to determine who should have access to information.
Some information is public, such as messages posted on a forum: anybody can
read it. However, customer bank details, personal information protected by
data protection legislation and connection details (login and password) could
cause devastating damage if they are leaked. For example, when attackers were
able to obtain login information from extramarital dating websites [ITE 15]:
the impact was disastrous for the company that failed to properly protect its
data.
Below Table 2.1 is an example of a confidentiality assessment grid.
Level Description
1. Public Information accessible to all
2. Limited Information only accessible to employees and partners
3. Reserved Information only accessible to the relevant internal
employees
4. Private Information only accessible to identified individuals who
need access to it
Table 2.1. Level definitions for the confidentiality scale
Level 1 corresponds to general information, such as the information
published on public websites. Level 2 usually corresponds to the information
handled by administrative applications. Individuals with access can
manipulate this information with no special restrictions.
Level 3 is applicable to personal data, such as bank transactions and
balances. This should only be accessible to the individuals to whom it relates
(in this example, the bank customers) and personnel authorized to view or](https://image.slidesharecdn.com/28026383-250512081332-3330d6d7/85/Safety-Of-Web-Applications-Risks-Encryption-And-Handling-Vulnerabilities-With-Php-Ric-Quinton-34-320.jpg)
![26 Safety of Web Applications
Level 4 is more restrictive: the information may not be modified once it
has been validated. For example, the Chamber of French Notaries [NOT 15]
has developed an application that allows notarized documents to be
electronically signed. Once they have been signed, they cannot be modified.
The architecture for implementing this is much more complex and relies on
archiving and electronic signing technologies.
2.4.3. Availability
Availability defines the period during which it is acceptable for the data,
or the application, to be inaccessible. If the application for booking meeting
rooms stops working for a few days, it will nevertheless be possible to revert
to manual scheduling in the interim. But supermarket cash registers cannot
afford interruptions of more than a few seconds or minutes.
Table 2.3 provides an example of an availability scale.
Level Description
1. More than 72 h The application can be unavailable for more than 72 h
2. Between 24 and 72 h The application must restore availability within 3 days
3. Between 4 and 24 h The application must restore availability within 24 h
4. < 4 h The application must restore availability within 4 h
Table 2.3. Level definitions for the availability scale
The choice of availability requirements will directly affect the cost of the
solution that is ultimately implemented. Three days is plenty of time for an
interruption to be resolved (this is enough time to reinstall the server and
restore the data), but as the target recovery period becomes shorter,
guaranteeing availability becomes increasingly complex to achieve.
If the target is to restore availability within less than 1 day, a backup
platform is required, ready to be activated in the event of an incident. An
administrator is also needed to monitor this platform and make the necessary
arrangements.
To restore availability within half of a day, the recovery mechanisms need
to be automated, and data need to be synchronized between the production
platform and backup platform. And if no downtime whatsoever is acceptable,](https://image.slidesharecdn.com/28026383-250512081332-3330d6d7/85/Safety-Of-Web-Applications-Risks-Encryption-And-Handling-Vulnerabilities-With-Php-Ric-Quinton-37-320.jpg)
![30 Safety of Web Applications
knowledge, they become more complex over time: even though simple attacks
still exist (SQL code injection remains the most common type of attack, due to
how easy it is to execute), much more sophisticated scenarios have also begun
to emerge. A single person or even a company will find it highly difficult to
even just stay informed of all possible types of attack and prepare appropriate
counter-measures, let alone anticipate these attacks independently.
It is probably simpler, less expensive and safer to rely on existing
benchmarks.
Many commercial companies have chosen to specialize in vulnerability
testing. In government contexts, Computer Emergency Response Teams
(CERTs) [WIK 16a] have been founded and regularly publish notices
detailing the security issues that they find. In France, the primary CERT is
operated by ANSSI, but there are also other dedicated CERTs, e.g. one for the
French academic research network.
CERTs inform us of vulnerabilities as they are discovered, but only rarely
provide a comprehensive overview of the security measures that need to be
taken.
There also exist archives of specifications designed to assist developers in
their work. ANSSI published a document listing recommendations for securing
websites [ANS 13]. Although this contains a wealth of information relating to
general organization and log management, the recommendations remain fairly
general, and their programming-related aspects are unspecific.
2.5.1. ASVS requirements
Fortunately, a non-profit American foundation, the Open Web Application
Security Project (OWASP [OWA 15a]), has been working to make the web
more secure, and offers a wide selection of tools and documents in open
formats. This is probably the most comprehensive open-source reference for
web application security.
Founded in 2001, it has been actively sponsored by major companies,
including big names such as Adobe, Hewlett Packard, Saleforce and Oracle,
but also by universities from all over the world.](https://image.slidesharecdn.com/28026383-250512081332-3330d6d7/85/Safety-Of-Web-Applications-Risks-Encryption-And-Handling-Vulnerabilities-With-Php-Ric-Quinton-41-320.jpg)
![Estimating Risk 31
Among other activities, the project regularly publishes a list of the top 10
most frequent types of web attack [OWA 13]. They also offer a tool for
simulating attacks to test the robustness of an application or website.
Finally, the Application Security Verification Standard (ASVS) subproject
has developed a grid of good practices that can be applied to web development
projects [OWA 14a]. A summary of this was prepared by a contributor in the
ODS format (the LibreOffice spreadsheet file type), with French translations
available on the Internet [OWA 14b]. A French adaptation of version 3 is also
available [QUI 16].
The security requirements listed in this document are categorized into three
levels, depending on the complexity of their implementation or that of the
attacks they are designed to foil.
Level 1, the opportunistic level, includes 82 items. These should be
implemented in every web development project. They protect against
so-called opportunistic attacks, i.e. attacks that are conducted randomly in
order to find incidental security flaws.
Level 2, the standard level, lists 144 requirements, and is useful for
applications that require a much higher security level. These measures protect
against targeted attacks with relatively limited resources.
Level 3, advanced, presents 175 requirements that must necessarily be
implemented in all critical projects. The objective of these measures is to
achieve good robustness against complex attacks, and to set up mechanisms
that are likely to identify and report suspicious behavior that might indicate
attempted intrusion (sometimes referred to as weak signals).
Even meeting the opportunistic-level standards requires some thought and
modifications to the code compared to a naive approach with no special
protective measures. Level 2 is more difficult to achieve, and can require
relatively complex procedures to be implemented, such as resource
controllers that check whether operations are being processed within certain
time parameters.
Level 3 on the other hand requires strong expertise, adequate resources
and proven code architecture: this is far beyond what is achievable by web](https://image.slidesharecdn.com/28026383-250512081332-3330d6d7/85/Safety-Of-Web-Applications-Risks-Encryption-And-Handling-Vulnerabilities-With-Php-Ric-Quinton-42-320.jpg)
![3
Encryption and Web Server Configuration
3.1. Examples of different web servers
The nature of web software programs, which send pages to the user’s
browser (also known as web servers), has changed dramatically in recent
years.
The 2000s were dominated by competition between Apache software
[APA 16] and Microsoft-based servers, Internet Information Server (IIS)
[MIC 16].
Although Apache servers are now the most commonly used type of server,
a newcomer, NGINX [NGI 16], has recently begun to gain in popularity,
renowned for its performance. IIS has largely disappeared and is seldom used,
except for very specific platforms.
Each of these servers is configured using different principles. Whereas
Apache governs the behavior either from a global configuration file or from
.htaccess files placed directly within the file system, NgInx works differently,
with one single file for each application (website name), usually saved in the
/etc/nginx/sites-enabled folder. This makes code review easier: you do not
need to browse the entire tree to determine the system configuration, but it
also has disadvantages, especially in the context of hosting platforms.
Specifying the desired settings is not always possible, since access to the file
might be prohibited.](https://image.slidesharecdn.com/28026383-250512081332-3330d6d7/85/Safety-Of-Web-Applications-Risks-Encryption-And-Handling-Vulnerabilities-With-Php-Ric-Quinton-46-320.jpg)
![36 Safety of Web Applications
Each of these web servers can adopt the same configuration, even though
the actual commands for doing so can differ. There would be little interest in
giving one presentation for each type of server; we will only give examples for
Apache, which is the most common, used by almost 50% of all active websites
[NET 16].
3.2. Introduction to concepts in encryption
Encryption is the process of modifying a message so that it becomes
incomprehensible to anybody who does not know the key or decryption
method. We distinguish two main types of encryption: symmetric encryption,
and its variant, hashing, and asymmetric encryption. The implementation of
the latter is based on digital certificates.
3.2.1. Symmetric encryption
Symmetric encryption (or private-key encryption) uses the same key both
to encrypt and decrypt the message.
A cipher is applied to the information being encrypted. One of the
parameters of this cypher is a key known only by the sender and receiver
(Figure 3.1).
Given the key and the cipher, the encrypted message can be decrypted by
applying the inverse cipher associated with the key.
There are two techniques for doing this. Block ciphers divide the message
into several parts of equal size (between 64 and 256 bits, depending on the
algorithm). This is the most common type of encryption in computer systems.
Stream ciphers encrypt the message bit by bit: this technique is mainly used for
radio transmission systems (GSM – cellphone networks, Bluetooth – wireless
networks, for example).
The size of the key itself is typically between 56 and 256 bits.
The strength of a symmetric cipher depends on several factors. The longer
the key, the more secure the encryption. It is widely believed that a key of 256
bits (2256 is approximately 1077, which is estimated to be close to the number](https://image.slidesharecdn.com/28026383-250512081332-3330d6d7/85/Safety-Of-Web-Applications-Risks-Encryption-And-Handling-Vulnerabilities-With-Php-Ric-Quinton-47-320.jpg)
![38 Safety of Web Applications
functions are applied to the data). However, they have a disadvantage: the
sender and the receiver must first exchange the secret key. Over an Internet
connection, confirming the identities of the sender and the receiver is
problematic, and the key must be transmitted in such a way that nobody else
can see it. We will see below that asymmetric encryption provides a solution
to this problem.
3.2.2. Computing hashes and salting passwords
In computing, a hash is a fixed-length sequence of characters calculated
from a file or an arbitrary sequence of characters. The hash is unique: it is
impossible to obtain the same hash from different data. But if the algorithm
is not sufficiently secure or the number of possible combinations is too small,
there can be collisions, i.e. two different strings can lead to the same hash1.
Finally, it should not be possible to reconstruct the original information from
the hash.
There are two main situations in which hashes are useful. The first is when
we wish to verify that a copy of a file is identical to the original, for example
when downloading an ISO image. The website hosting the download
indicates the hash value, and specifies the method used to calculate it. Once
the file has been downloaded, it is easy to recalculate the hash and check that
both values are identical. If there is a difference, the downloaded file is not
identical to the original, either due to an error during transmission or
interference from a hacker, which typically takes the form of a
man-in-the-middle attack [WIK 15a]. In this type of attack, the attackers
position themselves between the client’s computer and the web server, and
rewrite the transmitted information in real time.
Hashes are also used to encode passwords in such a way that they cannot
be decoded.
A special procedure can be used to store passwords. When the password is
created, its hash is calculated, and the hash is stored in the database. To check
the password, the program calculates the hash of the string entered by the user,
and then compares it to the value stored in the database. If the two hashes are
identical, the password is accepted as correct (Figure 3.2).
1 Today, the md5 algorithm is no longer used alone, primarily because of this weakness.](https://image.slidesharecdn.com/28026383-250512081332-3330d6d7/85/Safety-Of-Web-Applications-Risks-Encryption-And-Handling-Vulnerabilities-With-Php-Ric-Quinton-49-320.jpg)
![Encryption and Web Server Configuration 41
The message encrypted with key 1 can only be decrypted with key 2. The
reverse is also true: the message encrypted with key 2 can only be decrypted
with key 1.
In practice, the first key is kept secret by its owner: it is referred to as the
private key. The second key, the public key, is transmitted to all recipients that
request it.
This mechanism provides an easy way of accomplishing two different
tasks: encrypting messages and verifying the identity of a communication
partner.
If Bob wants to send an encrypted message to Alice, he retrieves her public
key, and uses it to encrypt his message. Alice can then decrypt the message
using her private key: she is the only one able to do so, as she is the only one
who knows the private key.
Now, if Alice sends a message to Bob, and Bob wants to be certain that
it was definitely Alice who sent it, the procedure is a little more complicated
(Figure 3.4).
The following sequence of operations is performed:
– Alice calculates the hash of her message using a hash function as
discussed above;
– she encrypts the hash using her private key;
– she sends a message with the encrypted hash to Bob;
– Bob receives this message, and calculates its hash;
– he decrypts the encrypted hash sent by Alice using her public key;
– finally, he compares both hashes: if they are identical, then it must have
been Alice who sent the message.
Of course, this protocol is carried out automatically, and these calculations
are performed by software programs, such as email clients like Thunderbird
[MOZ 15].
Asymmetric encryption is relatively robust because it is currently not
possible to quickly factor the product of two prime numbers if they are](https://image.slidesharecdn.com/28026383-250512081332-3330d6d7/85/Safety-Of-Web-Applications-Risks-Encryption-And-Handling-Vulnerabilities-With-Php-Ric-Quinton-52-320.jpg)
![42 Safety of Web Applications
chosen to be sufficiently large (there are other algorithms for managing
asymmetric keys based on elliptic curves rather than prime numbers; these
algorithms do not require the keys to be so large).
Hash
Encrypted
Hash
PRI
Encrypted
Hash
PUB
Hash
Decrypted
Hash
= ?
Figure 3.4. Principle of asymmetric encryption-based signatures
As it currently stands, the prime numbers used to generate the keys must
have sizes of at least 2048 bits to guarantee that they are robust. Even today,
ANSSI recommends using keys with 3096 bits, especially if they are intended
to remain in usage until after 2030.
3.2.4. What is the ideal length for encryption keys?
The figures listed here are taken from a document published by ANSII
[ANS 14].
Here are some examples that give an idea of the orders of magnitude
involved.](https://image.slidesharecdn.com/28026383-250512081332-3330d6d7/85/Safety-Of-Web-Applications-Risks-Encryption-And-Handling-Vulnerabilities-With-Php-Ric-Quinton-53-320.jpg)
Safety Of Web Applications Risks Encryption And Handling Vulnerabilities With Php Ric Quinton
- 1. Safety Of Web Applications Risks Encryption And Handling Vulnerabilities With Php Ric Quinton download https://ebookbell.com/product/safety-of-web-applications-risks- encryption-and-handling-vulnerabilities-with-php-ric- quinton-56052766 Explore and download more ebooks at ebookbell.com
- 2. Here are some recommended products that we believe you will be interested in. You can click the link to download. Safety Of Web Applications Risks Encryption And Handling Vulnerabilities With Php 1st Edition Ric Quinton Auth https://ebookbell.com/product/safety-of-web-applications-risks- encryption-and-handling-vulnerabilities-with-php-1st-edition-ric- quinton-auth-6614872 Safety Of Genetically Engineered Foods Approaches To Assessing Unintended Health Effects 1st Edition National Research Council https://ebookbell.com/product/safety-of-genetically-engineered-foods- approaches-to-assessing-unintended-health-effects-1st-edition- national-research-council-56327718 Safety Of Meat And Processed Meat 1st Edition Birgit Nrrung https://ebookbell.com/product/safety-of-meat-and-processed-meat-1st- edition-birgit-nrrung-2382174 Safety Of Historical Stone Arch Bridges 1st Edition Dirk Proske https://ebookbell.com/product/safety-of-historical-stone-arch- bridges-1st-edition-dirk-proske-4107200
- 3. Safety Of Research Reactors International Atomic Energy Agency https://ebookbell.com/product/safety-of-research-reactors- international-atomic-energy-agency-4107202 Safety Of Nanoparticles From Manufacturing To Medical Applications 1st Edition Robert A Hoerr https://ebookbell.com/product/safety-of-nanoparticles-from- manufacturing-to-medical-applications-1st-edition-robert-a- hoerr-4193520 Safety Of Electromedical Devices Law Risks Opportunities 1st Edition Univprof Dipling Dr Norbert Leitgeb Auth https://ebookbell.com/product/safety-of-electromedical-devices-law- risks-opportunities-1st-edition-univprof-dipling-dr-norbert-leitgeb- auth-4194042 Safety Of Vver440 Reactors Barriers Against Fission Products Release 1st Edition Vladimr Sluge Auth https://ebookbell.com/product/safety-of-vver440-reactors-barriers- against-fission-products-release-1st-edition-vladimr-sluge- auth-4195072 Safety Of Computer Architectures 1st Edition Jeanlouis Boulanger https://ebookbell.com/product/safety-of-computer-architectures-1st- edition-jeanlouis-boulanger-4443540
- 6. Safety of Web Applications
- 7. Series Editor Jean-Charles Pomerol Safety of Web Applications Risks, Encryption and Handling Vulnerabilities with PHP Éric Quinton
- 8. First published 2017 in Great Britain and the United States by ISTE Press Ltd and Elsevier Ltd Apart from any fair dealing for the purposes of research or private study, or criticism or review, as permitted under the Copyright, Designs and Patents Act 1988, this publication may only be reproduced, stored or transmitted, in any form or by any means, with the prior permission in writing of the publishers, or in the case of reprographic reproduction in accordance with the terms and licenses issued by the CLA. Enquiries concerning reproduction outside these terms should be sent to the publishers at the undermentioned address: ISTE Press Ltd Elsevier Ltd 27-37 St George’s Road The Boulevard, Langford Lane London SW19 4EU Kidlington, Oxford, OX5 1GB UK UK www.iste.co.uk www.elsevier.com Notices Knowledge and best practice in this field are constantly changing. As new research and experience broaden our understanding, changes in research methods, professional practices, or medical treatment may become necessary. Practitioners and researchers must always rely on their own experience and knowledge in evaluating and using any information, methods, compounds, or experiments described herein. In using such information or methods they should be mindful of their own safety and the safety of others, including parties for whom they have a professional responsibility. To the fullest extent of the law, neither the Publisher nor the authors, contributors, or editors, assume any liability for any injury and/or damage to persons or property as a matter of products liability, negligence or otherwise, or from any use or operation of any methods, products, instructions, or ideas contained in the material herein. For information on all our publications visit our website at http://store.elsevier.com/ © ISTE Press Ltd 2017 The rights of Éric Quinton to be identified as the author of this work have been asserted by him in accordance with the Copyright, Designs and Patents Act 1988. British Library Cataloguing-in-Publication Data A CIP record for this book is available from the British Library Library of Congress Cataloging in Publication Data A catalog record for this book is available from the Library of Congress ISBN 978-1-78548-228-1 Printed and bound in the UK and US
- 9. Preface When I first began my career in the 1980s, personal computing was in its infancy. The first computers had very little internal memory, so files and even entire booting routines were stored on floppy disks with very low storage capacity. Graphical interfaces did not yet exist, or in some cases were just beginning to be introduced. To exchange information with other users, we used floppy disks, and more powerful computer systems used magnetic tapes. Mainframe computers were accessed by passive terminals connected together with dedicated cables (one cable per terminal). These were called serial links. During the 1990s, as computing power increased, direct wired connections were gradually replaced by networks, and terminals were replaced by PCs. Computers then began to start dialoguing with each other internally, within companies. However, exchanges between different locations were limited, since communication costs were exorbitant and only very low bandwidths were possible. Applications were written for specific operating systems, which were in perfect control of their environments: all monitors had the same characteristics, as did all computers (PCs). In the late 1990s, the development of the Internet and the creation of the first websites open to the general public profoundly changed the lay of the land. The shift from dedicated applications on specific devices to the more general form of web applications deeply disrupted approaches to programming. Now, anyone can connect to any software, access information, order products, manage their emails, and so on.
- 10. xii Safety of Web Applications In the 2000s, with the proliferation of wireless connections (WiFi only really began to become widespread in France in the mid-2000s), the developer community also began to become aware of the security problems associated with this new environment. Before then, problems had been relatively well-isolated, since IT professionals were rare and also because systems enjoyed perfect control of their technical environments. This does not mean that security was completely neglected (encryption has always existed), but rather that, as a general rule, only companies or organizations that handled sensitive information (banks, military, etc.) paid any special attention to security. For most companies, the risk of data loss was very often the only factor taken into consideration, and even then only very loose protective measures were taken. The identify of users was also typically verified using unencrypted logins and passwords, since the risk of this information being intercepted was still relatively low. The available computer equipment was not yet powerful enough to implement “real-time” encryption anyway. But individuals, and in some cases organizations, quickly realized the potential financial and later political advantages that could be obtained by targeting these web applications: the Internet was no longer static as in its early days (initially, web pages could not be modified), but had now become dynamic. Now, users themselves can request specific behavior from the server, and influence the information that is presented to them. Web applications thus acquired a new dimension of risk: the information submitted by the browser needs to be systematically checked. Unanticipated behavior can occur if the user sends data specially modified with the objective of causing the server to react differently. This is, for example, the case with SQL injection, which, without the appropriate security measures, tricks the server into executing operations that were not planned by the programmer. Today, web software development requires an extremely varied spectrum of skills (programming languages such as PHP, HTML for drawing pages, CSS for stylizing them uniquely, JavaScript and its extensions such as JQuery for building interactivity, SQL for accessing databases, etc.). Many programmers learn these languages without necessarily being made aware of the risks to which they are exposed. Basic training rarely focuses on these aspects (with the exception of specialized training), or only addresses some of them, preferring to focus on more rudimentary skills. It is all too
- 11. Preface xiii common to meet newly qualified developers with very little knowledge of how to secure their software. This is also often true with self-taught students, who learn to program to meet a specific need, such as setting up a website for an organization, or who write interfaces to control small databases. Yet the risks are ever-present: without special protective measures, data can be corrupted, and the website can be used as a gateway by an attacker seeking to take control of the company information system, or might be defaced for politically motivated reasons. Taking the time to examine the security of an application is therefore particularly important. The first step of this process is to perform risk assessment: a banking application is more sensitive than a system for booking meeting rooms. The next step is to consider the runtime environment of the program. This might not be intrinsically safe: if the machines that host the application are not well protected themselves, any protective measures built into the code will be essentially useless. Similarly, exchanges between the server and users must be encrypted to prevent undesirable eavesdropping, or malicious modifications to the exchanged information performed in real time. Of course, these considerations begin to exceed the scope of just the program code, but one should note that encryption mechanisms are widely used by a large number of routines, in particular for the guarantees that they can provide for certain types of operation. Understanding the risks to which the code is exposed is a complex topic, simply due to the sheer variety of the potential mechanisms by which it could be attacked. Fortunately, there exist projects such as OWASP that regularly publish lists of the most common types of attack, each of which can often be thwarted by a few lines of code. ANSSI, the French National Agency for Information Systems Security, also regularly publishes advice and risk analysis methodology in the form of the EBIOS method. One important aspect of security is managing users and their access rights. Several different mechanisms can be used to identify users and allow them to access the information that they need. Designing an application is a complex task, and the only way to ensure that security measures are correctly applied everywhere is to structure the code
- 12. xiv Safety of Web Applications accordingly. Organizational methods, such as the MVC model (model, view, controller), can be used to fulfill these needs, and ensure that the application operates both reliably and securely. Finally, testing the developed software with special tools will allow us to identify the most obvious shortcomings. This is an important step before beginning production, and provides users with a guarantee that the necessary precautions have been taken to anticipate risks. This book presents a large number of examples. Most of them are written in PHP, which is one of the most common languages for creating web applications. These examples can of course be adapted to fit other languages. Often, only a few lines of code is required to patch a vulnerability, and the algorithm or approach used to tackle the problem is more interesting than the actual code itself. Éric QUINTON February 2017
- 13. 1 Why Do Web Applications Need to be Secure? 1.1. What is a web application? An application, or program, may be defined as a set of instructions that can be interpreted by a computer system, involving data. A web application is a program whose user interface runs in the browser, and whose logic is processed by a server, i.e. a remote machine. The browser and the server communicate over a network, the web – a collection of computer equipment and cables that allows information to be exchanged, and a protocol, the Internet. 1.1.1. The Internet, a global network The Internet is a protocol for exchanging messages between computers whose earliest foundations date back to the 1960s, but which first became truly operational in the 1980s. Each machine was originally identified by a unique address called an IP address (Internet Protocol), based on the principle that any computer should be able to communicate with any other. If we were to draw a diagram of the connections between all of the devices, it would look like a gigantic spiderweb – hence, the name web. The Internet is a network: the services built on top of it are what makes it special. The Internet allows messages to be exchanged via email, direct discussions to be held via forum protocols (most popular in the 1990s), and, of course, information to be viewed on the user’s screen due to the HTTP protocol. The primary reason that this protocol was developed is that it allows
- 14. 2 Safety of Web Applications users to navigate from one piece of information to the next in no specific order, using hyperlinks – this is known as surfing. To make navigating easier, the original IP addresses were replaced with names that are easier to remember. In practice, IP addresses still exist, but translation servers Domain Name Service (DNS) are used to perform the conversion. Most websites begin with the famous three letters World Wide Web (WWW). This term encompasses all servers that provide information viewed through browsers, which are programs installed on user devices that allow webpages to be displayed. The current version of the web dates back to the early 1990s. This is when the HTML format was invented for designing webpages. At the time, however, the concept of web application was not yet familiar. 1.1.2. Programs before the web Before the World Wide Web, programs were generated differently according to system on which they were intended to run: a program running on a Macintosh computer could not be used with another computer with a different operating system – the program that controls the computer – such as Windows. Programmers were faced with a difficult problem: how could they write an application that can run on all systems? In the late 1990s, the company Sun (which has since been acquired by Oracle) gave the first answer to this question by creating Java. Java is based on two building blocks: a programming language and an execution layer programmed specifically for each operating system. Windows Linux IOS JRE JRE JRE Java Program Figure 1.1. Working principle of Java applications
- 15. Why Do Web Applications Need to be Secure? 3 Any program written in Java can be run on any platform with the execution layer, the Java Runtime Environment (JRE), without requiring the code to be recompiled. The main drawback is that the JRE must be installed on each computer that runs the application. The program itself must also be distributed to each user and installed on each computer. Clearly, this solution is not yet completely ideal. 1.1.3. Web technology is gradually adopted by applications IT professionals soon realized how powerful the web could become. To create programs, we can simply run a piece of code on the server that generates the pages dynamically, depending on what the user wishes to see. Any browser can operate this program, no matter where it is hosted, so long as the user has an Internet connection. Windows Browser App1 App 2 Linux Browser App 1 App 2 IOS Browser App 1 App 2 Site 1 Site 2 Figure 1.2. Working principle of web applications Each computer has its own operating system (Windows, Linux, or IOS in this example). One specific program, the browser, is installed on each device: it can display any page returned by a website. If this page is created dynamically, that is to say, if it is recalculated by the website server each time that it is requested to adapt it to each request submitted by the user, we describe it as a web application. In this case, the server generates pages using a suitable language. Historically, PHP was one of the first languages to be used, but since then, there have been others, such as Python and Java.
- 16. 4 Safety of Web Applications In the early 2000s, HTML could not rival the performance of programs written specifically for each operating system, or developed in Java (or other languages working according to similar principles). Since then, it has vastly improved (we are currently using version 5), and we can now program actions to execute directly in the browser, for example by using the JavaScript language. Note that JavaScript has nothing to with Java, except for a certain similarity in the syntax and in the name. Today, applications written using web technologies are no longer inferior to those developed specifically for a given operating system in most respects. They can be executed in the browser, regardless of the system that drives the browser, and boast a wide range of features. However, one problem was soon discovered: the technologies that allow computers to communicate, which are sometimes described as the network layer, were not designed to be secure. The original designers mainly focused on the reliability of transmissions: the primary objective was to ensure that the messages exchanged between computers arrive safely at their destinations. At the time, very few people cared about guaranteeing confidentiality, and computers were not yet powerful enough to offer real-time encryption in the form that we are familiar with today. 1.1.4. Exchange is based on trust Fundamentally, the Internet is not secure: without complementing it with other technologies, everybody can listen to the information being exchanged, or even modify it in real time. Although this is generally not too much of a problem when viewing general information, it becomes an issue when updating databases, operating machinery and paying taxes: some level of confidentiality is necessary for these tasks. Today’s web only works because it relies on trust. For example, when we buy a product from a website, we must first trust the seller: we trust that the product that they are offering is available, and we trust that it will be delivered. The seller also needs to be sure that the delivery address given by the customer cannot be modified, etc. As for the payment, providing the credit card number is always tricky: the seller, or the bank acting
- 17. Why Do Web Applications Need to be Secure? 5 as an intermediary for the seller, must guarantee both the confidentiality of the exchange and the security of the collected data. This trust is an essential concept: although it was not fully necessary in primitive societies (as everybody could keep an eye on the whole community), this is no longer true today, since we need to conduct trades without knowing the other party personally. The need for security when interacting with others is indispensable, and relies not just on legal protective measures and regulations (the fact that companies must register on the Trade Registry, the risks involved with fraud, etc.), but also on the security processes in place to ensure that a third party cannot interfere with an interaction. To close the security gaps (everything is open and accessible by default), a number of technical solutions have been implemented to provide secure access to servers, encrypt connections, and ensure that data cannot be intercepted. It has also proven necessary to protect users themselves from information theft: if no special precautions are taken, a program provided by a server can easily access data on the user’s computer and steal information. To counter this, browser publishers have implemented a large array of security measures, for example by preventing webpages from accessing information on the user’s computer. This is the main limitation of web applications: they are forbidden from interacting directly with the device. Smartphones and tablets can circumvent this limitation, at the cost of requiring the application to be specially encapsulated. Today, these devices have a wide range of features, such as GPSes, cameras, accelerometers (which record movements and are, in particular, used to automatically rotate the screen), etc. To create an application that exploits these features using web technologies, multiple different languages are used, such as HTML, to prepare the displayed pages, and JavaScript, to manage the interactions with the device. The pages (the program) thus created are then encapsulated with special tools that make them usable. In this phase, access rights are granted to the finished application, which requests access to the hardware. To install these programs, virtual stores hosted by the operating system publishers (Google Play Store for Android, for example) act as an intermediate step, guaranteeing that the programs do not contain any malicious code that might compromise the system security.
- 18. 6 Safety of Web Applications 1.1.5. Bad idea: trusting that the intranet is automatically secure It might seem tempting to treat applications obtained directly from the Internet differently from those that only run internally (within the intranet of an organization). Although the risks are of course much higher with Internet applications, which are directly accessible by everyone in the world, we must not forget that even trusted personnel can behave inappropriately and attempt to modify information, whether for their own benefit or to harm the company for which they work. Furthermore, many modern attacks work by taking control of one computer, which is then used as a springboard to assault other devices until, step by step, a server containing confidential information is reached. While it is relatively natural to remember to secure an open web application downloaded from the Internet, it also makes sense to do the same for software that was not necessarily designed to be deployed outside of the company setting. Indeed, if, for whatever reason, it is made available at a later point in time, doing so will require fewer modifications, which will usually be limited to configuring the required network infrastructure. If security is not integrated into the design from the beginning, it will be much more complicated to implement later, and the effort required to develop additional protection modules can quickly become prohibitive. 1.2. What is computer security? The proliferation of computers and the Internet means that we need to store and retrieve information from digital media on a daily basis, as well as perform operations controlled by computers. If I want to make a bank transfer, I need the bank website to work, to display the correct information (the accuracy of my bank balance is important to me!), and I need to know that nobody else can access this information without my permission, or complete a transaction without my knowledge. This example shows the three criteria required for me to trust my bank. First, availability: does the website always work when I need it to, and can I perform the transactions that I want, when I want? Second, confidentiality: am I the only person that can check my balance, with the exception of
- 19. Why Do Web Applications Need to be Secure? 7 properly authorized bank personnel? Finally, integrity: is the information provided accurate and complete? Securing an application or a website consists of implementing mechanisms that will allow users to place some level of trust in the host’s ability to guarantee certain standards of confidentiality, availability and integrity. 1.2.1. Security relies on many different blocks Contrary to what one might think at first glance, the security of a web application does not only depend on its code, but also on several other factors, such as the server, the network architecture, etc. Today, the only device that is considered to be intrinsically safe is the smart card (at least in terms of data integrity and confidentiality – it can still be lost or destroyed): it does not require any other device to guarantee that it is secure. In every other case, several different blocks must collaborate to ensure that an application is protected. Below is a diagram showing an example of a fairly standard technical architecture used for web platforms: Firewall Web Server Database Firewall Figure 1.3. The different building blocks required to access a web application over the Internet Consider a workstation equipped with a browser that connects to the Internet in order to access an application. It sends a request that is
- 20. 8 Safety of Web Applications immediately processed by an initial firewall: a system that blocks all incoming connections unless they are authorized. In the case shown in the figure, the firewall only allows requests relating to access to the web server. Once the request has passed through the firewall, it is handled by a dedicated server, the reverse proxy. This is a web server that simply modifies the destination address of the request and performs a few additional checks to ensure that the user does not know anything about the server that receives the request. This is often the level at which measures are taken to protect against attacks designed to saturate a machine, also known as Denial of Service attacks or DoS (see section 3.5.3). A second firewall is then set up, which regulates access to the local network. Only connections originating from the reverse proxy server and headed toward the web server are allowed through. This firewall is often part of the web server, in the form of a program that filters connections originating from the network. The web server hosts the application, which processes the submitted request. If necessary, the application queries the database to retrieve or store any information that it might need. Each system plays a part in the overall security of the application. Depending on their roles, they influence either the confidentiality, availability or integrity. Firewall Firewall Availability Integrity Web Server Database Integrity Confidentiality Figure 1.4. The different blocks that participate in the security of the application
- 21. Why Do Web Applications Need to be Secure? 9 The hardware primarily acts to meet the need for availability: if a machine experiences a failure, the application will cease to be accessible. The integrity-related protections provided by this level are most closely linked to loss of data: the technical mechanisms that are implemented must ensure that no information is lost by maintaining backups, system redundancy, etc. The application itself must guarantee confidentiality, and to a lesser extent data integrity, in particular to ensure that attackers cannot modify information without authorization. Thus, to secure an application, we must not only consider the actual code, but also its execution environment. 1.2.2. Not all applications are equal in terms of security needs I do not need all applications to guarantee the same level of security: although inconsistencies in my bank statements would be unacceptable to me, I would probably not care too much about an unavailable or erroneous weather forecast, unless my activities that day are closely linked to the weather. Implementing security mechanisms costs time and money. For example, in order to guarantee that a program will be operational 24 hours a day, a backup server room is likely necessary, in case the primary server room experiences an incident (power outage, fire, etc.). In vital industry sectors, these rooms need to be sufficiently distant from each other that if the whole facility is destroyed, for example by a natural disaster or an industrial accident, the backup server room still remains unaffected. The cost of communicating between these two rooms will probably be higher if they are more than a few kilometers apart, and will require lines to be leased from operators. There are several methods for defining the required security level. Some methods use reasoning based on the availability, i.e. the hardware chain on which the application runs. In which case, the companies would study and implement a business continuity plan. This plan takes local factors into account (is the company located in a flood zone, or near a high-risk establishment?) as well as the security objectives. For the program, the security study attempts to define the expectations in terms of confidentiality, integrity and availability (this information must be
- 22. 10 Safety of Web Applications consistent with the business continuity plan). The risk posed to the business by any possible source of failure is evaluated. This is used to define the level of security that must be met by the future application: does it just need to be capable of resisting opportunistic attacks, i.e. randomly conducted attacks? Or does it need to be resistant to attacks that target it specifically? Is the risk sufficiently high that every possible measure must be taken to ensure maximal robustness? We will begin by studying the concepts used by business continuity plans, and we also continue to discuss how to evaluate the security level required by a program. 1.3. Examples of damage caused by security failures Thirty years ago, when I first started my career, computer security was scarce. Although the first viruses had already begun to bother us, they could only propagate via floppy disks (which had a storage capacity of 1.44 Mb!), so they were not a major concern. Furthermore, very few people knew anything about computers: security by obscurity! In the 1990s, I came across examples of important applications used to pay subsidies whose main administrative account for the database was not even password-protected! But since networks and the Internet did not yet exist, there was limited risk, and only few IT professionals were capable of system penetration. Today, the situation is radically different. Due to state-sponsored and corporate espionage parties with malicious intent, etc., coupled with a network that is available everywhere and a certain impunity originating from the architecture of the Internet network itself, not to mention the fact that large parts of the population are skilled in computer technologies, attacks have now become commonplace. Implementing a new application is often necessary or even critical for business activities in today’s competitive environment. However, applications can also cause problems if their security is compromised: financial losses, time, reputation and legal repercussions are examples of the possible cost of failure.
- 23. Why Do Web Applications Need to be Secure? 11 A few years ago, there was a Dutch company in the business of providing digital certificates, most notably used by the HTTPS protocol for encrypting traffic between browsers and web servers. The HTTPS protocol, as we will see in section 3.4, uses two keys: a public key (the digital certificate) and a private key, which must be kept secret. The public key is signed by a certificate authority: if this authority accidentally reveals the private key used to sign certificates, anybody can generate them, and website owners can no longer be reliably authenticated. This company was targeted by a cyber-attack, and its root certificate (the private key) was stolen: the hackers were therefore able to generate as many certificates as they wanted, allowing them to easily intercept traffic and generate false certificates to mislead users. The root certificate was very quickly revoked and deleted from users’ browsers. Consequently, all other certificates that it had been used to generate were also revoked. The company had to declare bankruptcy [WIK 15c]: the cyber-attack led to its ruin. Not every example is this serious, but the consequences can nevertheless be significant. It shows that the risks must be taken into consideration from the earliest stages of the project. In recent years, shop cash registers have been automated, i.e. operated by a remote server. Imagine what would happen if the computer system fails on the Saturday afternoon before Christmas: it would not be possible to record any payments. Clearly, this risk must be considered by the analysis: the loss of revenue would largely cover the costs of implementing a backup solution. In a similar spirit, many companies save credit card numbers – not just banks, but also large Internet-based traders, such as Amazon and Google. Although there are many advantages for companies in having the card payment information of their customers (purchasing is faster and encouraging more impulsive buying), this requires trust. If a website accidentally reveals the payment information of its customers, there is a good chance that they will want to switch providers. Unfortunately, this kind of incident does in fact happen on a regular basis, even to banks and the companies that issue cards on their behalf [LEM 14].
- 24. 12 Safety of Web Applications Similarly, if an attacker manages to modify the details of an order, for example by changing the shipping address of the items ordered by customers to an arbitrary location, they will be able to cause significant damage, both to the company’s finances and reputation. It is highly unlikely that a customer that has been duped in this way will wish to return to the same website to place another order. In the same way, we should not make the mistake of believing that confidential applications are safe from these kinds of attempt. Imagine a research laboratory that develops an application for data entry. If this application is poorly designed, it can, in some cases, allow code to be executed directly on the server that hosts it. If an attacker manages to corrupt the way that it normally operates, they can infiltrate the server, from where it is highly likely that they will be able to access the full information system of the laboratory, allowing them to search for more valuable information. Just because some access paths are well protected (this is often the case for network interconnection equipment in the world wide web) it does not mean that their content is fully inaccessible. A five-meter-high wall is not much use if a door is accidentally left open, or if it is only secured by a simple latch that can easily be opened from the inside. Anybody with access to the door can leave it open: this is what can happen if an attacker manages to take control of a server or an internal computer system. Sometimes, the stakes are high enough that attackers are willing to spend vast resources to penetrate a system. You might, for example, remember the incident suffered by the Iranian states a few years ago. Iran was attempting to enrich uranium to produce enough material to make an atomic bomb. This enrichment was performed by a centrifuge system: since uranium isotopes have different masses, the centrifuge can separate the minerals by causing the heavier elements to move outward. A particularly well-designed cyber-attack [BEN 10] destroyed the centrifuges by making them spin too rapidly. It probably required months of preparation by exceptionally competent teams. Experts estimated that this attack set the Iranian nuclear program back by at least 1 year, which was enough to change the direction of their national policy and facilitate subsequent negotiations.
- 25. Why Do Web Applications Need to be Secure? 13 Similarly, international politics can change extremely quickly, and a company or an organization that seems unexposed can very quickly find themselves in the spotlight, targeted by a coordinated retaliatory attack. Although there are many different possible vectors for an attack, searching for flaws in web software is often one of the simplest routes. If an application is poorly protected and an attacker manages to modify its usual behavior so that it allows them to install a malicious program on the server, they will be able to target other components of the company’s information system. Many security experts no longer ask: Can this system be attacked? but rather: When will it be attacked? This does not mean that we should give in to paranoia: the risk should be studied, and there are always ways to make life difficult for any would-be attackers. But we should remember that no system is impenetrable, even though some systems are more difficult to beat than others. 1.3.1. Do not take anything for granted Security is a lesson in modesty: no matter what you do, some clever attacker will be able to find a way to bypass it. Applications that seemed reliable 10 years ago can be easy to hack today. Over the last few years, attacks have become increasingly sophisticated. It is not uncommon for attackers to work for several months to prepare an attack, devoting substantial human and financial resources to their task. This is far from the mental image of a brilliant teenager bringing government institutions to their knees! Of course, the attack needs to be “worthwhile” relative to the invested resources. But even with applications that are not highly critical, the risk is never zero: opportunistic attacks can, for example, be mounted on websites that rely on a shared framework using newly discovered security vulnerabilities. It is easy for attackers to exploit these kinds of vulnerability, allowing them to access valuable information or gain access to other components that theoretically should have been better protected. For example, many websites are built with the WordPress publishing engine [WOR 15], one of the most popular content management systems. A serious vulnerability was discovered in 2014 [ZDN 14]: all websites using this engine became vulnerable to attack. As it always takes some time
- 26. 14 Safety of Web Applications for vulnerabilities to be patched (they require an update, which can take time, especially if the website is not managed by IT teams with experience in this kind of task), attackers can randomly launch attacks, hoping to stumble upon an unprotected website. After penetrating the system, they can publish a political message, or attempt to directly access the computer and find information that they can monetize. 1.3.2. Well-structured applications are easier to secure There is always something that we can do to limit the risk. The first step is to define the security level required by the application. Display websites that present a company and only contain general information (industry sector, services offered) are not as sensitive as sales websites or payroll management systems. If the architecture of the application is properly designed, it will be easier to implement additional security checks. For example, we can rely on models designed according to the MVC paradigm (model – view – controller). One particular aspect of this model is its unique controller (or a single family of controllers inheriting from this unique controller), which serves as a gateway (see Chapter 6). Similarly, data are sent to the browser using views1: any checks or formatting implemented in these views is performed once for each output. The model itself (and in particular the part of the model that accesses the database) is also based on a single object responsible for guaranteeing that information remains secure. If there is no single gateway, implementing any additional security functions requires each page to be updated one by one. Not only does this quickly become tedious, but individual pages might be omitted, or mistakes might accidentally be introduced into the code. 1 There can be multiple types of view, depending on the nature of the information to be transmitted: webpages, but also JSON files in response to an AJAX request, CSV files, PDF files, etc.
- 27. Why Do Web Applications Need to be Secure? 15 When I performed the security review of one of my most recent applications using the documents published by Open Web Application Security Project (OWASP) [OWA 15a], which we will encounter later), I found a vulnerability that I was not previously aware of. My application expected UTF-8 encoding, which could be exploited by certain types of attack to execute malicious code. The solution is to check that any input data are indeed encoded with UTF-8 . In fact, there is a simple PHP function that performs this check. Closing the security gap was as simple as adding 20 or so lines of code to the beginning of the controller code (see section 4.3.1). Thus, I was able to protect the entirety of my application against an unanticipated type of attack simply by modifying a single file, the controller. 1.3.3. The only type of security that matters is global security Except for smart cards, which are intrinsically secure (their security does not depend on third-party mechanisms, as we mentioned earlier), a computer system can only be considered secure if it is implemented within certain conditions. Imagine an application equipped with the latest state-of-the-art security measures. If it is deployed on a server that is left completely open, all of these security measures will be essentially useless: illegitimate access to the server will allow attackers to circumvent all protective measures. We will discuss how to implement a certain number of security measures in web applications, but we will also discuss how the servers themselves must be configured. This will allow us to define rules that should be applied during production, and to clarify the general context that needs to be available before we can consider an application to be reasonably secure relative to the chosen objectives. These rules are not a replacement for the work performed by network architects to properly protect servers and local networks: layers are often added to make things more difficult for attackers, such as firewalls that block some types of attack, antiviruses installed on the network equipment and proxies that allow servers to work through indirect connections to the world wide web, etc. Of course, it is rarely the responsibility of the developer to implement these protective measures. But it may be fruitful to open a dialogue with technical
- 28. 16 Safety of Web Applications teams to discover whether certain checks are already provided by the platform, to avoid having to include them in the application code. This is especially true for some aspects that relate to changes in the web server configuration, which might be performed either globally or application by application. 1.3.4. What security measures are required by applications with heavy clients? All too often, people only examine the security of web applications. One might be tempted to think that applications executed entirely from within a workstation are unlikely to be attacked from the outside. However, this is not the case. Applications handle information, and this information is probably valuable to the company. If a database is used by an application, and this database runs on the computer, it might potentially be accessed by other applications. Indeed, by default, local databases are not password-protected, since they are not accessible from the computer network; but a malicious program downloaded from a website might also attempt to access this database. This is in fact a common mechanism for attacking smartphones. Furthermore, it is likely the case that the data handled by the PC will be transferred to the company information system: how is this transfer conducted? Finally, laptops are easily stolen while traveling. If confidential data are not properly protected, this can quickly cause problems. Today, these risks are exacerbated by smartphones, which run all kinds of applications. Before developing software for this type of platform, good practice dictates that we should first consult the documents published by OWASP [OWA 15a], which describe the checks that should be made, depending on the sensitivity of the application. There are sections dedicated to these platforms. Thus, even for applications with heavy clients, it is advisable to conduct a security assessment, and if necessary to implement the appropriate protective measures. This is true on every operating system, whether Android, Windows, Linux or IOS: if a target is considered to be significant in some way, attackers
- 29. Why Do Web Applications Need to be Secure? 17 will be prepared to develop specialized attacks, even for less common platforms. We will not particularly focus on this aspect of security: one should simply remember that care is required when storing sensitive information (login details, credit card numbers, etc.), that developing robust login strategies for embedded databases is preferable (whenever applicable) and that in many cases the very first measure that should be taken is to encrypt the storage medium. We must bear in mind that there is always a potential risk, and that this risk must be estimated: this will allow us to develop a solution that is appropriate for our needs.
- 30. 2 Estimating Risk 2.1. What is risk? Risk is a relatively elusive concept. It can be expressed as the combination of the possibility of an event, a target and an impact. Consider an example from everyday life. If someone drives too fast on a mountain road, they risk crashing, which would result in some degree of damage or injury. The event associated with the risk is the crash, which represents the consequence of speeding. Together, these two points form a scenario, i.e. a series of necessary prerequisites for the accident to occur. The probability of the event depends on the driving speed, road and weather conditions, traffic, etc. The target is the car and the people inside, as well as any external objects involved in the accident (property, passers-by, etc.). Finally, the impact is the result of the damage caused, which can range from mild (a few scratches on the body of the car) to serious (death or hospitalization of a person). Thus, we can represent the risk in terms of these four factors: the cause or the scenario, the probability of occurrence, the target and the impact (Figure 2.1). This model can easily be adapted to describe the potential damage to an information system, for example due to an insecure web application.
- 31. 20 Safety of Web Applications Cause Impact Probability Target Risk Figure 2.1. Risk 2.2. How can we protect ourselves from risk? Once the risk has been identified, there are several possible strategies for preventing it from materializing, or for mitigating its impact. Returning to our example of mountain driving, there are multiple possible approaches. The first is to avoid driving in the mountains, and to choose safer roads, which might, however, increase the length of the voyage. We could also equip the car with specialized tires (e.g. snow tires in winter), and ensure that all passengers fasten their seatbelts. Finally, driving carefully, at a controlled speed, is another way of providing security. The EBIOS method1 proposes four strategies for managing risks: avoidance, reduction, transfer or acceptance. Avoidance consists of selecting an option that renders the event improbable, for example taking the highway or canceling the trip. In terms of computer systems, this might correspond to the decision to avoid computerizing a procedure if the risk for the company is disproportionate to the expected benefits. Reduction involves implementing measures to limit either the probability or the impact of the risk (snow tires, seatbelt, controlled speed, etc.). In 1 There are several global methods for defining the computer security requirements of a company. In France, two methods are predominantly used (but others exist): MEHARI [CLU 15a], proposed by CLUSIF, the French Information Security Club [CLU 15b] and EBIOS [ANS 10], proposed by ANSSI, the National Agency for Information Systems Security [ANS 15]. These methods restate or comply with the international ISO norms for risk management [ISO 09, ISO 11, ISO 15].
- 32. Estimating Risk 21 development projects, this includes most of the implemented security measures, as well as data backup mechanisms, for example. Transfer consists of asking a third party to assume responsibility for the risk. Thus, instead of driving a car, we could decide to travel by bus: the transportation company and their driver will instead be responsible for the risk. Of course, we do not have to choose the tour operator at random; we can base our decision on objective information (regulations, company reputation, etc.). For computer systems, choosing a web host that guarantees 24/7 availability falls into this category. Similarly, another example is when an SME sends a copy of its data to a service provider offering a cloud-based product: the data are entrusted to a third party with the facilities and servers to adequately protect against loss. Again, the choice of provider and the contract between both parties is not left to chance, and it is important to verify beforehand that the third party will be capable of effectively fulfilling the responsibility that is transferred to them. Finally, accepting the risk in its current form may be a viable choice. For example, a program used to book meeting rooms in a company can afford to be somewhat unprotected: if information is lost or corrupted, the risk of disruption is small. But this option can only be taken as part of an informed decision, and must not be the default course of action: if problems do arise, the absence of decision would be blamed on the person who had implemented the project. 2.3. Determining the target Consider once again the diagram showing a typical example of the technical architecture behind a web application (Figure 2.2). Two potential targets are shown. The target on the left largely concerns aspects relating to the network, server operation and safeguards against intrusion. It is relevant when drafting a business continuity plan, and when studying the risk associated with network infrastructure. The second, on the right, corresponds to our web application project. It includes software components corresponding to the web server, the application itself and the database.
- 33. 22 Safety of Web Applications Firewall Firewall Web Server Database Figure 2.2. Determining the target The target can be refined depending on the maturity of the company. If security measures are already in place and operational at the web server level, they do not need to be re-examined by the study. Similarly, if the database server is fully protected, and specific procedures are imposed on the developers, then this aspect does not need to be included either. The choice of target is particularly important: if chosen too small, it is highly likely that security gaps will slip through. If too large, the study will become more complex, and redundant security measures might be proposed, which cost time and money. Typically, risk analysis for IT development projects is limited to the web server, or at least the implementation of the application within this server, the program itself and its connections with the database(s). 2.4. Determining the impact This is probably the most complicated component of risk analysis (we will see that the scenario analysis can be transferred). The impact is determined in two steps. First, the security needs are estimated, and then the impact of failure is evaluated. The security needs are usually determined according to three criteria, also known as CIA (from the first letter of each criterion): confidentiality, integrity
- 34. Estimating Risk 23 and availability. The criteria are usually graded from 1 to 4, where 1 is the lowest level of need and 4 is the highest level. These assessment grids are filled out by the company, which adapts them to their environment and effective needs. Example grids are of course available; a few examples are presented below, and others are available from ANSSI [ANS 10]. 2.4.1. Confidentiality Confidentiality aims to determine who should have access to information. Some information is public, such as messages posted on a forum: anybody can read it. However, customer bank details, personal information protected by data protection legislation and connection details (login and password) could cause devastating damage if they are leaked. For example, when attackers were able to obtain login information from extramarital dating websites [ITE 15]: the impact was disastrous for the company that failed to properly protect its data. Below Table 2.1 is an example of a confidentiality assessment grid. Level Description 1. Public Information accessible to all 2. Limited Information only accessible to employees and partners 3. Reserved Information only accessible to the relevant internal employees 4. Private Information only accessible to identified individuals who need access to it Table 2.1. Level definitions for the confidentiality scale Level 1 corresponds to general information, such as the information published on public websites. Level 2 usually corresponds to the information handled by administrative applications. Individuals with access can manipulate this information with no special restrictions. Level 3 is applicable to personal data, such as bank transactions and balances. This should only be accessible to the individuals to whom it relates (in this example, the bank customers) and personnel authorized to view or
- 35. 24 Safety of Web Applications change the data. Furthermore, customers should not be able to view information that is not theirs. Finally, in this context, level 4 corresponds to data that should not be accessed or changed except by personnel who actually require access to it, regardless of their credentials or hierarchical position. This principle is used to manage classified military information. Up to level 3, access can be managed by the application itself. At level 4, complex encryption and permissions procedures and possibly computer network isolation protocols are likely to be necessary. 2.4.2. Integrity Integrity defines whether it is acceptable for information to be corrupted or lost, and the required conditions for restoring data. This criterion combines two different aspects. The first relates to the loss of information: a server failure or a mistake can cause data to be lost. In the best-case scenario, it will be possible to recover to an intact previous state, if backups are available and can be used for restoration, or if the database is configured to track all operations (for example using application logging techniques or by synchronizing between servers). In this respect, integrity primarily consists of defining acceptable time periods for data loss. It would be unacceptable for a bank transaction to be lost, due to the economic significance of each transaction. However, it is acceptable for an office file to be lost if an earlier, fairly recent version can be recovered. Classical backup systems work with time steps of half-days or days, which is often sufficient. Losing a file is never pleasant, but in many cases reconstructing it is relatively easy, although this of course takes time and creates frustration. This criterion is evaluated by choosing the maximum admissible data loss, which will in particular determine the technical environment required by the application (database synchronization for remote environments, backup policies, etc.).
- 36. Estimating Risk 25 The second aspect relates to the corruption of information: corrupted information is still present, but has been modified, either unintentionally by a computer error or an erroneous operation or voluntarily by a deliberate act. In some cases, this may not be serious, as it may be possible to revert to a previous state, for example using backups. In other cases, it may pose more of a problem, for example in the case of bank transactions or legal documents. In these cases, the application must incorporate mechanisms for guaranteeing the integrity of information, either by redundant self-checking systems, or by signing the data to guarantee that it has not been modified. Table 2.2 provides an example of an integrity scale. Level Description 1. Modifiable The information being processed does not require integrity; the data may be modified without significant consequences 2. Detectable The information does not require integrity, provided that modifications are identifiable and it is possible to revert to a previous state if necessary by restoring from a backup 3. Controlled The information does not require integrity, provided that modifications are tracked and the information is retrievable; it is essential to monitor all modifications in real time (full logging procedures to track all changes) 4. Signed The information requires strict integrity in all circumstances, if necessary by an electronic signing or encryption procedure Table 2.2. Level definitions for the integrity scale Level 1 of this scale is rarely applicable. It could for example apply to internal applications whose content becomes irrelevant once it has been generated, such as the results of calculations that can be repeated. This describes any information that can be deleted without causing damage. Level 2 corresponds to systems with regular backup procedures. We can always revert to the previous state by restoring data from other media (for example laboratory notebooks). Level 3 does not allow any loss of information: database replication procedures, tracking logs, etc., are mandatory. This is typically the level required for banking transactions or just-in-time processes.
- 37. 26 Safety of Web Applications Level 4 is more restrictive: the information may not be modified once it has been validated. For example, the Chamber of French Notaries [NOT 15] has developed an application that allows notarized documents to be electronically signed. Once they have been signed, they cannot be modified. The architecture for implementing this is much more complex and relies on archiving and electronic signing technologies. 2.4.3. Availability Availability defines the period during which it is acceptable for the data, or the application, to be inaccessible. If the application for booking meeting rooms stops working for a few days, it will nevertheless be possible to revert to manual scheduling in the interim. But supermarket cash registers cannot afford interruptions of more than a few seconds or minutes. Table 2.3 provides an example of an availability scale. Level Description 1. More than 72 h The application can be unavailable for more than 72 h 2. Between 24 and 72 h The application must restore availability within 3 days 3. Between 4 and 24 h The application must restore availability within 24 h 4. < 4 h The application must restore availability within 4 h Table 2.3. Level definitions for the availability scale The choice of availability requirements will directly affect the cost of the solution that is ultimately implemented. Three days is plenty of time for an interruption to be resolved (this is enough time to reinstall the server and restore the data), but as the target recovery period becomes shorter, guaranteeing availability becomes increasingly complex to achieve. If the target is to restore availability within less than 1 day, a backup platform is required, ready to be activated in the event of an incident. An administrator is also needed to monitor this platform and make the necessary arrangements. To restore availability within half of a day, the recovery mechanisms need to be automated, and data need to be synchronized between the production platform and backup platform. And if no downtime whatsoever is acceptable,
- 38. Estimating Risk 27 high-availability mechanisms distributed over at least two different facilities are required to limit the risk of failure in one of these facilities (for example network or power outage). An increased number of staff is also required to manage this infrastructure. Therefore, determining the appropriate level of availability will strongly affect the total cost of the project and the complexity of its implementation. 2.4.4. Determining the level of risk associated with a project In the previous section, we discussed requirements in terms of availability, integrity and confidentiality. For each of these criteria, it is important to estimate the damage that could be caused if an incident occurs. For example, what would happen if the cash registers stop working for longer than 10 min? The risk is usually estimated using a four-level scale. Table 2.4 shows the examples given in the EBIOS method. Level Description 1. Negligible The impact will be overcome with no difficulty 2. Limited The impact will be overcome with some difficulty 3. High The impact will be overcome, but with serious difficulties 4. Critical The impact cannot be overcome, and the survival of the company is threatened Table 2.4. List of risk levels These risk levels are not assessed globally, but are usually structured into four categories: internal disruption, financial losses, company reputation and liability commitments (or legal risk). Internal disruption includes everything that relates to everyday business activities: this could range from delays in processing files to fundamental disarray, social movements, etc. The financial loss is the amount of money required to restore the systems after a failure, either in terms of revenue lost due to the failure, or expenditure required following third-party proceedings (financial penalties, court judgments, damages and interest, etc.).
- 39. 28 Safety of Web Applications The activities of any company rely heavily on their reputation with their customers. If a major software program (for example a web-based sales application) does not work or leaks confidential information, the company’s reputation and customer trust might be seriously compromised, which could jeopardize the future of the company. Finally, if the company is left open to legal proceedings following a security breach, in particular if contractual clauses had been drawn or the latest standards had not been complied with, the impact may be significant, resulting in high financial losses, high workloads, reputation losses, etc. After defining each of the criteria and establishing the impact table, one last important task still remains: defining the potential impact of failure for each criterion. The following summary Table 2.5 can be used. Criterion Required level Internal Financial Liability Reputation Max. impact Confidentiality Integrity Availability Table 2.5. Assessment table for the impact of failure The first column indicates the target level for each criterion. The estimated impact of failure is listed in each of the next four columns for each risk category. Finally, the last column summarizes the maximum risk exposure for that criterion. Crucially, the impact must be estimated at the level of the company itself, and not at the level of the software requester or their department. Indeed, when a security vulnerability is discovered, the company itself is called into question, not just its IT, financial or sales departments. This key distinction must be kept in mind: individuals will always tend to maximize any risks that concern them directly, due to the impact that they could have on their own career within the company. Imagine an incident that could cause internal users to lose confidence in a service. The software requester will likely estimate the level of risk to be fairly
- 40. Estimating Risk 29 high, at 3 or 4. However, at the level of the company, the actual risk might be much lower: it might prove necessary to reorganize a few services, which could indeed be a complicated task, or alternatively an employee may need to be dismissed or transferred, etc., but none of this would prevent the company from continuing to operate as usual. It is important to remember this nuance when performing risk analysis. Establishing an appropriate estimate that relates to the actual risk for the company will often avoid unnecessarily implementing heavy and expensive security procedures. Conversely, if a major risk is identified, it should be escalated to management, who must then decide whether the advantages of computerizing the procedure justify the associated risk, or authorize the appropriate resources to contain or handle this risk. 2.5. Which causes or scenarios should be considered? We have now estimated the impact of an information system failure from the perspective of the company. But, to protect ourselves, we still need to know what the potential threats might be. When establishing a business continuity plan, it is relatively easy to list all possible causes of failure: human risk, power or network outage, technological risk (facilities classified as being potentially dangerous), natural risk (flooding, earthquakes, fire, etc.) and so on. In the case of computer applications, this exercise becomes much more difficult. Although it is relatively easy to anticipate hardware failures (which should in principle be included in the business continuity plan), strictly cyber- based attack scenarios are much more difficult to enumerate. IT, and software development in particular, is an example of immaterial technology. This means that making programs work is not a mechanical process – designing these programs is an intellectual activity that heavily relies on the imagination. If two developers are given the same task without any particular restrictions, they will develop significantly different programs, both in terms of user-oriented approach and internal design. Cyber-attacks are also the fruit of the mind. They are the result of attempts to find new flaws that have never before been imagined. Like all forms of
- 41. 30 Safety of Web Applications knowledge, they become more complex over time: even though simple attacks still exist (SQL code injection remains the most common type of attack, due to how easy it is to execute), much more sophisticated scenarios have also begun to emerge. A single person or even a company will find it highly difficult to even just stay informed of all possible types of attack and prepare appropriate counter-measures, let alone anticipate these attacks independently. It is probably simpler, less expensive and safer to rely on existing benchmarks. Many commercial companies have chosen to specialize in vulnerability testing. In government contexts, Computer Emergency Response Teams (CERTs) [WIK 16a] have been founded and regularly publish notices detailing the security issues that they find. In France, the primary CERT is operated by ANSSI, but there are also other dedicated CERTs, e.g. one for the French academic research network. CERTs inform us of vulnerabilities as they are discovered, but only rarely provide a comprehensive overview of the security measures that need to be taken. There also exist archives of specifications designed to assist developers in their work. ANSSI published a document listing recommendations for securing websites [ANS 13]. Although this contains a wealth of information relating to general organization and log management, the recommendations remain fairly general, and their programming-related aspects are unspecific. 2.5.1. ASVS requirements Fortunately, a non-profit American foundation, the Open Web Application Security Project (OWASP [OWA 15a]), has been working to make the web more secure, and offers a wide selection of tools and documents in open formats. This is probably the most comprehensive open-source reference for web application security. Founded in 2001, it has been actively sponsored by major companies, including big names such as Adobe, Hewlett Packard, Saleforce and Oracle, but also by universities from all over the world.
- 42. Estimating Risk 31 Among other activities, the project regularly publishes a list of the top 10 most frequent types of web attack [OWA 13]. They also offer a tool for simulating attacks to test the robustness of an application or website. Finally, the Application Security Verification Standard (ASVS) subproject has developed a grid of good practices that can be applied to web development projects [OWA 14a]. A summary of this was prepared by a contributor in the ODS format (the LibreOffice spreadsheet file type), with French translations available on the Internet [OWA 14b]. A French adaptation of version 3 is also available [QUI 16]. The security requirements listed in this document are categorized into three levels, depending on the complexity of their implementation or that of the attacks they are designed to foil. Level 1, the opportunistic level, includes 82 items. These should be implemented in every web development project. They protect against so-called opportunistic attacks, i.e. attacks that are conducted randomly in order to find incidental security flaws. Level 2, the standard level, lists 144 requirements, and is useful for applications that require a much higher security level. These measures protect against targeted attacks with relatively limited resources. Level 3, advanced, presents 175 requirements that must necessarily be implemented in all critical projects. The objective of these measures is to achieve good robustness against complex attacks, and to set up mechanisms that are likely to identify and report suspicious behavior that might indicate attempted intrusion (sometimes referred to as weak signals). Even meeting the opportunistic-level standards requires some thought and modifications to the code compared to a naive approach with no special protective measures. Level 2 is more difficult to achieve, and can require relatively complex procedures to be implemented, such as resource controllers that check whether operations are being processed within certain time parameters. Level 3 on the other hand requires strong expertise, adequate resources and proven code architecture: this is far beyond what is achievable by web
- 43. 32 Safety of Web Applications development performed “on the back of a napkin”. Mobilizing development teams that specialize in security is essential for this. 2.5.2. Determining the relevant causes and their likelihoods of occurrence Using the ASVS grid to determine the requirements that need to be considered during development cirumvents the need to determine the causes and likelihood of occurrence of an attack. If there are no special stakes associated with an application, attackers will likely not be willing to devote significant lengths of time trying to penetrate it (unless they want to gain control of the company information system in search of more valuable data – but that is another story). Usually, they will not seek to orchestrate complex attack scenarios: the cost necessary to complete these scenarios would not be justified by the value of the data obtained or the damage caused. However, a sensitive program might be targeted by sophisticated attacks whose development can afford higher time investment and resources. The fact that the ASVS grid is divided into three levels therefore allows us to adjust the effort that we invest in securing an application as a function of the potential risk. The specific requirements listed under level 3 are designed to counter complex attack scenarios, but are also more complicated to implement than those listed under level 1. In EBIOS terminology, by using this table, we are transferring the responsibility for estimating causes and occurrences to it, depending on the desired security level of our application. 2.5.3. Choosing the level of requirements In the previous sections, we estimated the security needs and the impact of failure. It is tempting to use this information to define the level of security requirements. Table 2.6 provides an example that allows us to quickly identify the category of an application.
- 44. Estimating Risk 33 Level Description High The maximum impact in the event of a security failure is equal to 4 Standard The maximum impact in the event of a security failure is equal to 3 Minimal or opportunistic Other cases Table 2.6. Classification levels of the application Our security study has allowed us to determine the requirements that should be taken into consideration, which will strongly influence our approach to designing the application and launching it into production. 2.6. How should this study be performed in a company setting? Applications are only one block within the larger information system: it is not possible to guarantee that an application is secure without considering the technical environment that hosts it: servers, networks, workstations if applicable, etc. However, the way that it is designed and the risks that it protects against can directly affect the reputation of the company, as well as company profits, etc. The required security level cannot be defined by IT professionals on their own: the party requesting the application, who understands the need for it, is best placed to estimate the consequences of a security failure. Often, this step is performed by an approval procedure that is defined company-wide, at least in larger companies. We will not study this approval procedure in full detail here, as it is beyond the scope of this book. However, even without a formal procedure, it is always important for the software requester to be involved in defining the target security level. In general, it is also important to conduct risk assessment at an early stage of the decision process that will ultimately lead to the realization of the application. Risk assessment is an essential step: depending on its conclusions, changes in the software programming approach or the implementation of the host platform may be required.
- 45. 34 Safety of Web Applications This step must be performed by the functional project manager (also known as the project owner), and should be validated by the CEO or his/her representative: if a software program introduces high risks for the company, the decision to implement it should be taken by the highest authorities within the company. IT professionals can assist with this, but should not ever make the decision in place of the users or executives responsible for the program. In French government administration, all information systems (including applications) must be approved for information system security before they are commissioned. This approval is issued by a competent entity responsible for information system security (referred to by the French acronym AQSSI), which is usually the director of the relevant structure. This approval certifies that the necessary measures have been taken to protect against the risks created by the application.
- 46. 3 Encryption and Web Server Configuration 3.1. Examples of different web servers The nature of web software programs, which send pages to the user’s browser (also known as web servers), has changed dramatically in recent years. The 2000s were dominated by competition between Apache software [APA 16] and Microsoft-based servers, Internet Information Server (IIS) [MIC 16]. Although Apache servers are now the most commonly used type of server, a newcomer, NGINX [NGI 16], has recently begun to gain in popularity, renowned for its performance. IIS has largely disappeared and is seldom used, except for very specific platforms. Each of these servers is configured using different principles. Whereas Apache governs the behavior either from a global configuration file or from .htaccess files placed directly within the file system, NgInx works differently, with one single file for each application (website name), usually saved in the /etc/nginx/sites-enabled folder. This makes code review easier: you do not need to browse the entire tree to determine the system configuration, but it also has disadvantages, especially in the context of hosting platforms. Specifying the desired settings is not always possible, since access to the file might be prohibited.
- 47. 36 Safety of Web Applications Each of these web servers can adopt the same configuration, even though the actual commands for doing so can differ. There would be little interest in giving one presentation for each type of server; we will only give examples for Apache, which is the most common, used by almost 50% of all active websites [NET 16]. 3.2. Introduction to concepts in encryption Encryption is the process of modifying a message so that it becomes incomprehensible to anybody who does not know the key or decryption method. We distinguish two main types of encryption: symmetric encryption, and its variant, hashing, and asymmetric encryption. The implementation of the latter is based on digital certificates. 3.2.1. Symmetric encryption Symmetric encryption (or private-key encryption) uses the same key both to encrypt and decrypt the message. A cipher is applied to the information being encrypted. One of the parameters of this cypher is a key known only by the sender and receiver (Figure 3.1). Given the key and the cipher, the encrypted message can be decrypted by applying the inverse cipher associated with the key. There are two techniques for doing this. Block ciphers divide the message into several parts of equal size (between 64 and 256 bits, depending on the algorithm). This is the most common type of encryption in computer systems. Stream ciphers encrypt the message bit by bit: this technique is mainly used for radio transmission systems (GSM – cellphone networks, Bluetooth – wireless networks, for example). The size of the key itself is typically between 56 and 256 bits. The strength of a symmetric cipher depends on several factors. The longer the key, the more secure the encryption. It is widely believed that a key of 256 bits (2256 is approximately 1077, which is estimated to be close to the number
- 48. Encryption and Web Server Configuration 37 of electrons in the universe) can never be broken by brute force, i.e. by testing each combination in turn. However, the length of the key is not the only factor that determines the strength of the cipher. Messages are encrypted block by block, and the larger each block, the more robust the cipher. The same computation function is also applied multiple times (number of iterations). The greater the number of iterations, the more robust the cipher; ANSSI recommends performing 65,000 iterations. The relevancy of the algorithm itself must also be considered, and the key must be generated completely at random. encryption Cleartext message Encrypted message Key decryption Cleartext message Key Figure 3.1. Principle of symmetric encryption To improve security, especially for codes or passwords, limiting the number of permitted attempts is also a good idea. For example, smart cards are blocked after three unsuccessful attempts, which means that unlock codes with only 4– 6 digits are sufficient. Today, the most widely used algorithm is AES256: the blocks are 128 bits in size, and the key is 256 bits. It is currently believed to be secure. Symmetric encryption is inexpensive in terms of computation time, due to the simplicity of its algorithms (matrix permutations and boolean XOR-type
- 49. 38 Safety of Web Applications functions are applied to the data). However, they have a disadvantage: the sender and the receiver must first exchange the secret key. Over an Internet connection, confirming the identities of the sender and the receiver is problematic, and the key must be transmitted in such a way that nobody else can see it. We will see below that asymmetric encryption provides a solution to this problem. 3.2.2. Computing hashes and salting passwords In computing, a hash is a fixed-length sequence of characters calculated from a file or an arbitrary sequence of characters. The hash is unique: it is impossible to obtain the same hash from different data. But if the algorithm is not sufficiently secure or the number of possible combinations is too small, there can be collisions, i.e. two different strings can lead to the same hash1. Finally, it should not be possible to reconstruct the original information from the hash. There are two main situations in which hashes are useful. The first is when we wish to verify that a copy of a file is identical to the original, for example when downloading an ISO image. The website hosting the download indicates the hash value, and specifies the method used to calculate it. Once the file has been downloaded, it is easy to recalculate the hash and check that both values are identical. If there is a difference, the downloaded file is not identical to the original, either due to an error during transmission or interference from a hacker, which typically takes the form of a man-in-the-middle attack [WIK 15a]. In this type of attack, the attackers position themselves between the client’s computer and the web server, and rewrite the transmitted information in real time. Hashes are also used to encode passwords in such a way that they cannot be decoded. A special procedure can be used to store passwords. When the password is created, its hash is calculated, and the hash is stored in the database. To check the password, the program calculates the hash of the string entered by the user, and then compares it to the value stored in the database. If the two hashes are identical, the password is accepted as correct (Figure 3.2). 1 Today, the md5 algorithm is no longer used alone, primarily because of this weakness.
- 50. Encryption and Web Server Configuration 39 Password intialization qwerty Hash function 9ceece10cf8b... 9ceece10cf8b... Hash function qwerty Enter password Identical passwords Figure 3.2. Password verification using hashes Today, we extend this procedure with a technique known as salting. The hash is calculated from the data given to the hash algorithm. But if these data are predictable (password too easy to guess, for example), it can be relatively easy to recover the original data from the hash. This can happen in practice for passwords. Too many people choose passwords that are easy to guess: the strings password or 12345678, first names or the date of birth of a child or spouse, etc., are unfortunately very common choices. If an attacker knows the hashing algorithm and has access to the database following an intrusion or data theft, they will be able to run a search that will easily find some of these passwords. To protect against the risk of this type of attack, one solution is to mix in a piece of variable information when the hash is calculated. This variable information is different for each user. This is called salting. Usually, the account or login id, which is necessarily unique, is appended to the password: even if two users have the same password, this procedure results in different hashes. Below is an example with the password password and the two distinct user accounts john and mark (the code was generated using a Linux command):
- 51. 40 Safety of Web Applications echo johnpassword|sha256sum 88071 bcc ... We joined the username (john) and the password (password) together before computing the hash. We now do the same with a different username, mark: echo markpassword|sha256sum bd6e27fb08 ... The two hashes are different. Therefore, even though the passwords themselves might be the same, the values stored in the database are never identical. Even if the attacker knows the salting algorithm, they will be forced to recalculate all possible values for each account, which makes their task much more complex. 3.2.3. Asymmetric encryption Symmetric encryption is secure enough to protect communications, but it suffers from a fundamental flaw: the encryption key must be shared between both parties. Thus, we need a way to exchange the key without it being intercepted, while verifying the identity of the person with whom we are communicating. Asymmetric encryption provides a solution to this problem. Asymmetric protocols generate two keys instead of one, based on two randomly chosen prime numbers. The remarkable property of this procedure is that a message encrypted with one key can only be decrypted using the other: 1 2 Alice Bob Figure 3.3. Principle of asymmetric encryption
- 52. Encryption and Web Server Configuration 41 The message encrypted with key 1 can only be decrypted with key 2. The reverse is also true: the message encrypted with key 2 can only be decrypted with key 1. In practice, the first key is kept secret by its owner: it is referred to as the private key. The second key, the public key, is transmitted to all recipients that request it. This mechanism provides an easy way of accomplishing two different tasks: encrypting messages and verifying the identity of a communication partner. If Bob wants to send an encrypted message to Alice, he retrieves her public key, and uses it to encrypt his message. Alice can then decrypt the message using her private key: she is the only one able to do so, as she is the only one who knows the private key. Now, if Alice sends a message to Bob, and Bob wants to be certain that it was definitely Alice who sent it, the procedure is a little more complicated (Figure 3.4). The following sequence of operations is performed: – Alice calculates the hash of her message using a hash function as discussed above; – she encrypts the hash using her private key; – she sends a message with the encrypted hash to Bob; – Bob receives this message, and calculates its hash; – he decrypts the encrypted hash sent by Alice using her public key; – finally, he compares both hashes: if they are identical, then it must have been Alice who sent the message. Of course, this protocol is carried out automatically, and these calculations are performed by software programs, such as email clients like Thunderbird [MOZ 15]. Asymmetric encryption is relatively robust because it is currently not possible to quickly factor the product of two prime numbers if they are
- 53. 42 Safety of Web Applications chosen to be sufficiently large (there are other algorithms for managing asymmetric keys based on elliptic curves rather than prime numbers; these algorithms do not require the keys to be so large). Hash Encrypted Hash PRI Encrypted Hash PUB Hash Decrypted Hash = ? Figure 3.4. Principle of asymmetric encryption-based signatures As it currently stands, the prime numbers used to generate the keys must have sizes of at least 2048 bits to guarantee that they are robust. Even today, ANSSI recommends using keys with 3096 bits, especially if they are intended to remain in usage until after 2030. 3.2.4. What is the ideal length for encryption keys? The figures listed here are taken from a document published by ANSII [ANS 14]. Here are some examples that give an idea of the orders of magnitude involved.
- 54. Encryption and Web Server Configuration 43 2n 10n Order of magnitude 232 4,294,967,296 Number of people on Earth 246 7.036874418 × 1013 Sun–Earth distance, in millimeters 255 3.602879702 × 1016 Number of operations performed in 1 year at a rate of one billion per second (1 Ghz) 290 1.237940039 × 1027 Number of operations performed in 15 billion years at a rate of one billion per second 2256 1.157920892 × 1077 Estimated number of electrons in the universe Table 3.1. Some examples of orders of magnitude For secret-key encryption (symmetric keys), the minimum block size must be at least 64 bits (128 bits after 2020). The length of the encryption key must be at least 128 bits. It is believed that a key of length 256 bits will never be able to be broken by brute force. The decryption rules for asymmetric encryption are completely different: factoring procedures are used, which are easier to compute. The minimum size of the prime moduli, i.e. the moduli used to generate the keys, should not be less than 2048 bits (3072 bits for certificates intended to remain in usage after 2030). 3.2.5. Digital certificates and the chain of certification One of the problems with using asymmetric encryption lies in the fact that it is difficult to be sure that the public key, provided by Alice, is indeed hers and was not replaced by an attacker. One solution is to trust a certification authority that guarantees the validity of the public key. The certification authority signs Alice’s public key using the following procedure: – when Alice generates her two keys, she sends her public key to the certification authority; – the certification authority verifies Alice’s identity, for example by checking her identification documents, and then signs Alice’s public key by encrypting its hash with the certification authority’s own private key. The public key and the encrypted hash are stored in a digital certificate.
- 55. Random documents with unrelated content Scribd suggests to you:
- 56. Vaikka oli pimeä ja teitä risteili myötään, astui Vitalis kuitenkin varmasti niinkuin mies, joka tietää minne mennä ja tuntee tiet. Minä seurasin häntä pelkäämättä lainkaan, että voimme eksyä; siitä vain olin huolissani, että milloin vihdoinkin tuo louhos tulee. Mutta sitten Vitalis pysähtyi äkkiä. "Näetkös metsää?" kysyi hän minulta. "En näe mitään." — "Etkö näe mitään mustaa?" Minä katselin joka puolelle. Me olimme tulleet tasangolle, sillä katseeni katosi pimeään niin, ettei näkynyt mitään, ei puuta, ei taloa. Aavikko ympärillämme, eikä kuulunut muuta ääntä kuin tuulen tohina näkymättömissä pensaissa. "Ollapa minulla sinun silmäsi?" sanoi Vitalis. "Mutta minä näen niin huonosti. Katsohan tuonne." Hän ojensi kätensä. Kun minä en vastannut, sillä en uskaltanut sanoa, etten minä näe mitään, lähti hän astumaan. Kuljettiin muutamia minuutteja ääneti, niin hän taas pysähtyi ja kysyi vielä, enkö nähnyt metsää. Minä en ollut niin varma isäntäni osaamisesta kuin äsken, ja minua alkoi pelottaa, jonka vuoksi ääneni vapisi vastatessani, etten näe mitään. "Sinä pelkäät, ja sen vuoksi silmäsi vilisevät", sanoi Vitalis. — "Minä vakuutan, ettei näy mitään metsää." — "Eikö näy tietä?" — "Ei näy mitään." — "Me olemme eksyneet!" Minulla ei ollut sanaa suuhun tulevaa. Ei tietoa missä olimme eikä mihin oli mentävä. "Astutaan vielä viiden minuutin aika. Jollemme sitten näe metsää, niin palaamme takaisin. Minä olen eksynyt tieltä."
- 57. Nyt kun ymmärsin, että voimme olla eksyksissä, voimani alkoivat horjua. Vitalis veti minua kädestä. "No mikä nyt?"— "Minä en jaksa enää astua." — "No luuletko, että minä jaksan sinua kantaa? Ajattele vain, että jos istahdamme, niin emme siitä enää ikinä nouse, kuolemme siihen kylmään. Astu pois!" Minä seurasin häntä. "Onko tässä tiessä syvät raiteet?" — "Ei ole raiteita ollenkaan." — "Meidän pitää palata takaisin." Tuuli puhalsi nyt kasvoihin niin ankarasti, että olin aivan tukehtua. Tuntui aivan polttelevan. Tullessakaan emme olleet astuneet ylen kiireesti, mutta palatessa oli kulkumme tuiki hidasta. "Kun näet raiteet, niin sano minulle", sanoi Vitalis. "Oikean tien pitäisi olla vasemmalla, pensas tienhaarassa." Me astuimme jonkun neljännestunnin taistellen tuulta vastaan. Yön synkässä hiljaisuudessa askeleemme kaikuivat kovasti kohmettuneessa maassa. Vaikka olinkin niin väsynyt, että tuskin jalka jalasta siirtyi, niin minä se kuitenkin nyt talutin Vitalista. Sitä tuskaani, kun minä tarkastelin tien vasenta puolta! Pimeässä näkyi yhtäkkiä pieni punainen tähti. "Tuolta näkyy tuli!" sanoin ojentaen kättäni. Vitalis katseli, mutta vaikka tuli tuipotti niin suuresti, että se varmaankaan ei ollut kovin kaukana, ei Vitalis kuitenkaan nähnyt mitään. Siitä huomasin, että hänen näkönsä oli heikontunut, sillä tavallisesti hän yöllä näki kauas ja tarkasti.
- 58. "Ei meillä ole mitään hyötyä siitä tulesta", sanoi hän. "Se on lamppu, joka palaa jonkun työmiehen katossa tai kuolevan vuoteen ääressä. Emme voi mennä koputtamaan heidän ovelleen. Maaseudulla voisimme pyydellä päästäksemme huoneeseen, mutta Parisin ympäristössä ei olla vierasvaraisia. Meille ei ole ainoatakaan taloa. Astutaan tietämme!" Me astuimme vielä muutamia minuutteja, ja sitten olin näkevinäni tien kulkevan poikki meidän tiestämme ja tien kulmassa mustan haamun, joka varmaan oli pensas. Minä irtausin Vitaliksen kädestä ja menin edeltäpäin tarkastelemaan tätä tietä. Siinä olikin syvät raiteet. "Tuossa on pensas ja tässä on raiteet." — "Annahan tänne kätesi, me olemme pelastetut, louhos on viiden minuutin matkan päässä tästä. Katsohan tarkoin. Sinun pitäisi nähdä metsikköä." Minä olin näkevinäni jotakin mustaa haamua ja sanoin, että erotin puita. Toivo toi meille voimia, jalkani tuntuivat keveämmiltä, eikä maa tuntunut enää niin kovalta jaloissani. Kuitenkin Vitaliksen ilmoittamat viisi minuuttia tuntuivat minusta iankaikkisuudelta. "Olemme astuneet tätä tietä jo enemmän kuin viisi minuuttia", sanoi Vitalis pysähtyen. "Niin minustakin." — "Missä ovat raiteet." — "Ne menevät suoraan," — "Louhoksen suun pitäisi olla vasemmalla, me olemme varmaan kulkeneet siitä ohi, mikä on varsin helppoa näin pimeässä. Meidän olisi raiteista pitänyt ymmärtää, että menemme liian kauas." — "Minä vakuutan, että raiteet eivät ole kääntyneet vasemmalle." — "No käännytään takaisin."
- 59. Me käännyimme vielä kerran takaisin. "Näetkö metsikköä?" — "Näen, tuolla vasemmalla." — "Ja raiteet?" — "Niitä ei ole." — "Olenko minä sokea?" sanoi Vitalis pannen käden silmilleen. "Anna minulle kätesi ja astutaan suoraan metsikköä kohden." "Tässä on muuri." "Se on kivikasa." "Ei ole kivikasa, muuri se on." Me olimme ainoastaan muutaman askeleen päässä, muurista, ja Vitalis harppoi sen luo koettelemaan käsin, kun ei silmin saanut selvää esteestä, jota minä sanoin muuriksi ja hän kivikasaksi. "Muuri se on. Kivet ovat säännöllisesti ladotut, ja minä tunnen muurisaven. Mutta missä on aukko? Etsihän raiteet." Minä kumarruin maahan ja kuljin muurin sivua kahtaanne käsin tapaamatta raiteita. Siten kuljin toisaalle päin, mutta kaikkialla vain oli umpinainen muuri, eikä ollut mitään tietä, ei vähintäkään merkkiä aukosta. "En minä näe muuta kuin lunta." Isäntäni oli epäilemättä eksynyt tieltä, niin ettemme olleet löytäneet louhosta. Hän seisoi jonkun aikaa ääneti, sitten alkoi juosta muurin sivua toisesta päästä toiseen. Capi, joka ei ymmärtänyt tätä liikettä, alkoi levottomana haukkua. Minä kuljin Vitaliksen jäljessä. "Louhos on suljettu muurilla", sanoi Vitalis. "Me emme pääse sinne mistään." — "Mitäs sitten?" — "En tiedä. Ei suinkaan muuta kuin kuolla tähän."
- 60. Minulta pääsi tuskan huudahdus. "Niin, sinä et halua kuolla, sinä kun olet nuori ja elämään mielistynyt. No niin. Lähdemme astumaan. Jaksatko vielä astua?" — "Jaksatteko te?" — "Sitten kun en enää jaksa, niin kaadun kuin vanha hevonen." — "Minne lähdemme?" "Palaamme Parisiin. Kun tapaamme poliisikonstaapelin, niin annamme hänen kuljettaa meidät poliisivahtikonttoriin. Olisin halunnut välttää tätä, mutta en voi antaa sinun kuolla kylmään. Astutaan, Remini, astutaan, poikaseni. Eteenpäin!" Ja me lähdimme astumaan tietä, jota olimme tulleet. Mikähän aika nyt oli? En voinut aavistaakaan. Olimme astuneet pitkän aikaa, hyvin kauan ja hitaasti. Oli ehkä puoliyön aika. Taivas oli yhäkin musta, joitakin harvoja tähtiä tuikki, jotka näyttivät pienemmiltä kuin tavallisesti. Tuuli oli kiihtynyt. Se pyöritteli lunta tomuna tien laitamilla ja pieksi kasvojamme. Talot, joiden ohi kuljimme, olivat suljetut ja pimeät. Minusta tuntui, että jos ihmiset, jotka siellä nukkuivat lämpöisissä vuoteissaan, olisivat tienneet, miten meidän oli kylmä, niin he olisivat päästäneet meidät sisälle. Jos olisimme astuneet kiireesti, niin olisimme pysyneet lämpiminä, mutta Vitalis astui hitaasti ja huohottaen, aivan kuin olisi juossut. Kun häneltä jotakin kysyi, niin hän ei vastannut, kädellään teki vain liikkeen osotteeksi, että hän ei voinut puhua. Me olimme päässeet kaupunkiin, tahi oikeammin, me kuljimme keskellä muurilla aidatuita taloja. Vitalis pysähtyi äkkiä. Minä ymmärsin, että hän oli jo aivan uupunut. "Minä koputan jollekin portille?"
- 61. "Ei, he eivät avaa. Nämä tässä ovat puutarhureita, he eivät nouse tähän aikaan. Astutaan edelleen." Mutta hänellä ei ollut niin paljon voimia kuin tahtoa. Muutamia askeleita kuljettuamme hän pysähtyi taas. "Minun täytyy vähän levähtää", sanoi hän, "minä en enää jaksa." Muutamassa paaluaidassa oli portti, ja sen luona kohosi yli aidan lantatunkio. Tuuli oli kuivannut päällimmäiset oljet ja ajanut niitä kadulle aika vahvalta juuri paaluaidan seinämälle. "Minä istahdan tuohon", sanoi Vitalis. "Mutta te sanoitte, että jos istumme, niin kylmetymme emmekä enää voi nousta." Vastaamatta mitään hän viittasi minulle, että kokoaisin olkia portin luo, ja siihen hän sitten melkein putoamalla istahti. Hänen hampaansa kalisivat ja koko ruumiinsa tärisi. "Tuo vielä olkia", sanoi hän minulle. "Tunkiosta meillä on suojaa tuulta vastaan." Tuulta vastaan meillä kyllä oli suojaa, mutta ei kylmää vastaan. Kun olin tuonut siihen olkia niin paljon kuin sain kootuksi, istahdin Vitaliksen viereen. "Asetu aivan lähelle minua ja kutsu Capi päällesi, niin se lämmittää sinua vähän", sanoi Vitalis. Hän oli kokenut mies, joka tiesi, että kylmä näissä oloissa voi tuottaa kuoleman. Ja että hän antautui tähän vaaraan, se osotti, että hän oli uupunut. Parin viikon aikana hän ei ollut kertaakaan mennyt levolle niin, ettei olisi ollut aivan
- 62. uuvuksissa. Hän oli kovin rasittunut kestääkseen enää kaikkien näiden ponnistusten jälkeen, niin iäkäskin kun hän jo oli. Oliko hänellä tietoa tilastaan, en voi sanoa. Mutta kun minä olin koonnut oljet ja asettunut hänen viereensä puristautuen lähelle häntä, niin tunsin hänen kumartuvan ylitseni ja syleilevän minua. Se oli toinen kerta ja — viimeinen! Kun vuoteessa maatessa on vähän kylmä, niin se estää unta, mutta taivasalla maatessa kova ja pitkittyvä kylmä tekee tunnottomaksi. Niin kävi meidänkin. Heti kun olin paneutunut Vitaliksen viereen, kävin unteloiseksi ja silmäni sulkeutuivat. Minä koetin niitä avata, mutta kun en onnistunut, niin nipistin käsivarttani lujasti. Ihoni oli tunnoton, ja ainoastaan kun kaikin voimin puristin, tuntui jotakin vähäistä kipua. Mutta vilun puistatukset kuitenkin saivat minut vähän tajulleni. Vitalis, selin nojaten porttiin, hengitti vaivoin, hyvin lyhyeen ja nopeasti. Capi jo nukkui jalkapuolessani. Tuuli tohisi ylitsemme ja peitteli meitä oljenkorsilla, joita lenteli kuin kuivia lehtiä, jotka puista karisevat. Kadulla ei ollut ristinsielua: lähellä ja kaukana, kaikkialla kuolonhiljaisuus. Minua pelotti. Mikä? En voi sitä sanoa, mutta minä tunsin epämääräistä pelkoa, surunsekaista ahdistusta, joka sai kyyneleet silmiini. Minusta tuntui, että minä kuolen siihen. Ja kuoleman ajatus vei minut Chavanoniin. Barberinin äiti raukka! Kuolla tähän näkemättä häntä, näkemättä taloamme, puutarhaani. Ja tietämättäni harhaileva mielikuvitus vei minut tähän puutarhaan: aurinko paistoi iloisesti ja lämpöisesti, kukat aukoivat kultakupujaan, linnut visersivät pensaikossa ja äiti Barberin levitteli ruusupensaille vaatteita, joita hän tuli pesemästä purolta, mikä lorisi ruohikossa.
- 63. Yhtäkkiä olivat ajatukseni poissa Chavanonista, ja minä löysin itseni Joutsenesta: Arthur nukkui vuoteellaan, rouva Milligan oli hereillä, ja kun hän kuuli tuulen pauhaavan, niin hän kysyi, missä minä olen näin kylmällä ilmalla. Sitten silmäni sulkeutuivat uudestaan, sydäntäni kouristi ja minä menin tainnoksiin.
- 64. XVII. Herätessäni huomasin olevani vuoteessa, suuri tuli paloi kamarissa, jossa olin nukkunut. Huone oli minulle outo, samoin ihmisetkin, jotka olivat ympärilläni: yksi mies, neljä lasta, joista muuan oli pieni viisi- tai kuusivuotias tyttö, oka katseli minua ihmeissään. Hänen silmänsä olivat kummalliset, ne puhuivat. Minä nousin, ja kaikki kokoontuivat ympärilleni. "Missä Vitalis?" sanoin. "Hän kysyy isäänsä", sanoi muuan tyttö, joka näytti olevan vanhin lapsista. "Ei hän ole isäni, vaan isäntäni. Missä hän on? Missä on Capi?" Jos Vitalis olisi ollut isäni, niin varmaan olisi valikoitu sanoja hänestä puhuttaessa minulle, mutta kun hän ei ollut kuin isäntäni, niin päätettiin sanoa suora totuus, ja niin kerrottiin minulle koko asia. Me olimme kyyristyneet muutaman puutarhurin portin pieleen. Noin kahden aikaan aamulla oli puutarhuri avannut portin lähteäkseen torille ja oli silloin tavannut meidät makaamasta
- 65. olkikasassa. Ensin oli huudettu meitä siirtymään hevosen tieltä, ja sitten kun ei kukaan muu meistä liikahtanut kuin Capi, joka muristen ja haukkuen oli puolustanut meitä, niin oli tultu meitä käsivarresta pudistamaan. Me emme olleet liikahtaneet sittenkään. Silloin oli alettu ajatella, että tässä on jotakin arveluttavaa. Oli haettu lyhty, ja kun sen valossa tarkastettiin, niin huomattiin, että Vitalis oli paleltunut kuoliaaksi ja ettei minunkaan tilani ollut paljoa parempi. Mutta kuitenkin, kun Capi oli maannut päälläni, olin pysynyt siksi lämpimänä, että minä vielä hengitin. Minut oli kannettu puutarhurin taloon ja pantu maata sänkyyn. Siinä olin maannut kuusi tuntia melkein kuin kuollut; sitten veren kiertokulku oli päässyt uudelleen voimaansa, hengitys käynyt voimakkaammaksi ja minä heräsin. Niin jähmettynyt kuin olinkin sekä sielultani että ruumiiltani, olin kuitenkin siksi selvillä, että ymmärsin täydellisesti niiden sanojen merkityksen, jotka olin kuullut. Vitalis kuollut! Asian kertoi itse puutarhuri, ja sillä aikaa kuin hän puheli, tuo pieni tyttö, jonka katse oli niin kummallinen, ei hetkeksikään luovuttanut minusta silmiään. Kun hänen isänsä oli sanonut, että Vitalis on kuollut, niin tyttö varmaan ymmärsi tai yhtäkkiä huomasi, miten ankara isku se oli minulle, sillä hän meni kiireesti isänsä luo, asetti toisen kätensä hänen käsivarrelleen ja toisella viittasi minua, äännellen omituisesti, joka ei ollut lainkaan ihmisen ääntä, vaan aivan kuin hellä ja säälivä huokaus. "Niinpä niin, pikku Liseni", sanoi tytölle hänen isänsä, "se koskee häneen kovasti, mutta täytyy sanoa totuus, sillä jos emme me sitä sano, niin sanoo sen poliisi." Ja hän kertoi minulle, miten oli annettu tieto poliisille, miten miehet olivat kantaneet Vitaliksen korjuuseensa,
- 66. jotavastoin minut sijoitettiin hänen vanhemman poikansa Alexin vuoteeseen. "Missä Capi?" kysyin, kun hän oli lopettanut kertomuksensa. — "Capi!" — "Niin, koira?" — "En tiedä, se on kadonnut varmaan." — "Se seurasi ruumissaattoa", sanoi muuan lapsista. — "Näitkö sen, Benjamin?" — "Näin hyvinkin. Se seurasi kantajain kintereillä, allapäin, ja silloin tällöin se hyppäsi paareille, ja kun se ajettiin alas, niin se päästi sellaisen valittavan äänen, joka oli kuin ulvontaa." Capi raukka! Se oli niin monta kertaa hyvänä näyttelijänä seurannut Zerbinon ruumissaattoa, huokaillen niin, että lapset nauroivat katketakseen. Puutarhuri ja hänen lapsensa jättivät minut yksin, ja tietämättä mitä tein ja varsinkaan mitä oli tehtävä, nousin vuoteeltani. Harppuni oli asetettu jalkopäähän. Otin sen olalleni ja aioin lähteä huoneeseen, johon puutarhuri oli mennyt lapsineen. Olihan lähdettävä, mutta minne? … Siitä ei ollut tietoa, mutta sen vain tiesin, että lähdettävä oli… Mutta siinä kun olin päässyt jaloilleni, tuntui minusta, että kaadun, ja minun piti kiireimmiten istahtaa tuolille. Jonkun aikaa siinä levättyäni avasin kamarin oven ja olin puutarhurin ja hänen lastensa luona. He istuivat pöydässä iloisen valkean äärellä, joka paloi kamiinissa, ja söivät lämmintä velliä. Ruuan haju kiihotti vatsaani muistuttamaan minulle, että en ollut syönyt eilen illalla. Minua alkoi pyörryttää ja minä horjuin. "Voitko pahoin, poikaseni?" kysyi puutarhuri lempeällä äänellä. Minä vastasin niinkuin asia oli, että en voi hyvin, ja pyysin saada vähän aikaa levähtää tulen ääressä. Mutta minä en tarvinnut
- 67. ainoastaan lämmintä, vaan ruokaakin. Nuotio ei antanut minulle ravintoa, ja ruuan haju, lusikkain kalina ja lasten kielenmaiskutus vain lisäsi minun heikkouttani. Jos olisin rohjennut, niin olisin pyytänyt lautasellisen velliä! Mutta Vitalis ei ollut minua opettanut kättä ojentamaan eikä luonto ollut tehnyt minusta kerjäläistä. Olisin ennen vaikka nälkään kuollut kuin sanonut: "Minun on nälkä." Minkävuoksi? En osaa sanoa, jos ei liene syynä ollut se, että en koskaan ole tahtonut pyytää muuta kuin sitä, minkä voin maksaa. Tuo pieni tyttö, jonka katse oli omituinen, joka ei puhunut ja jota isänsä oli sanonut Liseksi, istui minua vastapäätä ja katseli minua kesken syöntiänsä, kääntämättä muualle silmiään. Yhtäkkiä hän nousi pöydästä ja toi minulle vellilautasensa, joka oli täysinäinen, ja asetti sen polvilleni. Minä tein liikkeen kiittääkseni häntä, sillä en jaksanut enää puhua, mutta hänen isänsä ehätti sanomaan: "Ota, poikaseni, mitä Lise tarjoaa. Jos se sinulle maittaa, niin saat toisenkin lautasellisen." Jos minulle maittaa! Muutamassa sekunnissa olin ahminut lautasen tyhjäksi. Kun panin lautaselle lusikkani, niin Lise, joka oli jäänyt viereeni ja katsellut minua, äännähti, mutta hänen äännähdyksensä ei tällä kertaa ollut huokaus, vaan osotti tyytyväisyyttä. Hän otti minulta lautasen, ojensi sen isälleen täytettäväksi ja toi sen sitten minulle niin lempeästi ja rohkaisevasti hymyillen, että minä nälissänikin unehduin häntä katsomaan hetkiseksi aikaa huomaamatta ottaa lautasta. Niinkuin ensi kerrallakin, niin nytkin katosi velli hyvin äkkiä. Nyt tyttö ei hymyillyt enää, vaan oikea nauru loisti hänen suupielistään ja huuliltaan. "Kas vain, poikaseni", sanoi puutarhuri, "sinähän olet kelpo lusikkamies."
- 68. Minä tunsin punastuvani hiusmartoa myöten, mutta sitten minusta tuntui paremmalta sanoa totuus kuin antaa syyttää itseäni ahmatiksi, ja minä selitin, etten ollut eilen syönyt. "Et ole syönyt eilen? No entä isäntäsi?" — "Ei hänkään." — "No sitten hän on kuollut nälkään ja kylmään." Velli oli minua vahvistanut, ja minä nousin lähteäkseni. "Mihin aiot mennä?" kysyi puutarhuri. — "En tiedä." — "Onko sinulla tuttavia Parisissa?" — "Ei ole." — "Mitä aiot tehdä?" — "Soittaa harppua." — "Parasta taitaisi olla, kun palaisit kotipuoleesi, vanhempaisi luo." — "Minulla ei ole enää vanhempia." — "Eikö sinulla ole sukulaisia, enoa, tätiä, serkkuja?" "Ei ainoatakaan. Isäntäni osti minut kasvatusäitini mieheltä… Minä kiitän sydämestäni teitä kaikesta hyvyydestä, jota olette minulle osottaneet, ja jos haluatte, niin minä palaan sunnuntaina soittamaan harppua tanssiaksenne, jos se teitä huvittaa." Minä olin menossa ovea kohden, kun Lise otti minua kädestä ja osotti harppuani hymyillen. "Haluatteko, että soittaisin?" Hän nyökäytti päätään ja taputti iloisena käsiään. "Niin, soitahan jotakin", sanoi isäntä. Minä tartuin harppuuni, ja vaikka mieleni ei ollutkaan iloinen, niin soitin valssia, pannen parastani. Olisipa minua haluttanut osata soittaa yhtä hyvin kuin Vitalis ja huvittaa tätä pientä tyttöä, joka silmillään teki niin suloisen vaikutuksen minuun.
- 69. Hän kuunteli katsoen kiinteästi minuun, sitten hän polki jalkaansa tahdin mukaan ja alkoi pyöriskellä, jolla aikaa hänen veljensä ja sisarensa pysyivät yhdessä kohdin istumassa. Hän ei tanssinut valssia eikä ottanut säännöllisiä askeleita, mutta hän pyöri viehättävän kauniisti, ilo silmistä loistaen. Hänen isänsä, joka istui kamiinin luona, katseli häntä kiinteästi; tyttö oli aivan ihastuksissaan ja taputti käsiään. Kun olin lopettanut soittamisen, niin hän asettui eteeni ja kiitti sievästi niiaten. Sitten hän heti näpähytti sormellaan harppuni kieltä merkiksi, että tahtoi "vielä". Minä olisin mielellänikin soittanut hänelle vaikka koko päivän, mutta hänen isänsä sanoi, että jo riitti, peläten tyttärensä väsyttävän itsensä. Minä senvuoksi tanssikappaleen sijasta soitin napolilaisen lauluni, jonka Vitalis oli minulle opettanut. Tämä laulu oli loistokappaleeni, jonka vaikutukseen olin tottunut luottamaan. Sen sävel oli vieno ja surullinen, siinä on jotakin hellää, joka liikuttaa mieltä. Ensimäiset sävelet kuultuaan asettui Lise katsomaan minua silmiin, liikuttaen huuliaan aivan kuin kertoen sanojani; sitten kun laulun sävel kävi surullisemmaksi, hän peräytyi muutamia askeleita, ja viimeisellä säkeellä hän itkien heittäysi isänsä syliin. "Jo riittää!" sanoi hänen isänsä. "Se on tyhmä!" sanoi Benjamin, hänen veljensä. "Ensin tanssii, sitten yhtäkkiä rupeaa itkemään."
- 70. "Ei hän ole niinkään tyhmä kuin sinä. Hän ymmärtää soittoa", sanoi vanhin sisar, kumartuen suutelemaan sisartaan. Minä otin harppuni hartioilleni ja lähestyin ovea. "Minne nyt?" kysyi puutarhuri. — "Lähden taipaleelle." — "Sinä olet mielistynyt soittaja-ammattiisi." — "Eipä minulla muutakaan ole." — "Eikö sinua pelota kulkea teitä?" — "Mikäs auttaa, kun ei ole kotia." — "Mutta eikö viime yö ole pannut sinua vähän arvelemaan?" — "Toki hyvinkin. Mieluisampaahan olisi hyvä vuode ja lämmin tuli." — "Jos tahdot, niin saat ne, työlläsi tietysti. Jos haluat, niin voit jäädä meille, tehdä työtä ja elää kanssamme. Tietysti ymmärrät, että minulla ei ole sinulle hyvyyksiä eikä laiskan päiviä tarjota. Jos suostut meille jäämään, niin suostut näkemään vaivaa, pitää nousta varhain aamulla, tehdä työtä kovasti koko päivä, otsasi hiessä syödä leipäsi, jonka ansaitset. Mutta sen sijaan sinun ei tarvitse maata taivasalla niinkuin viime yönä teit ja ehkä kuolla johonkin ojaan. Illalla on vuoteesi valmis ja syötyäsi olet tyytyväinen ansioosi. Ja vielä, jos sinä olet kelpo poika, niinkuin minä luulen, löydät kodin luonamme." Lise kyyneltensä läpi katseli minua hymyillen. Hämilläni tästä ehdotuksesta seisoin jonkun aikaa epätietoisena, osaamatta ajatella ehdotuksen merkitystä. Lise tuli luokseni, otti kädestäni ja talutti minut muutaman kuvan luo, joka riippui seinällä. Kuvassa oli pieni Johannes lampaannahkaisessa puvussa. Lise teki merkin isälleen ja veljilleen kehottaen heitä katsomaan kuvaa ja osottaen samalla minua, silittäen minun lammasnahkatakkiani, ja osottaen tukkaani, joka valui hartioilleni kähertyneenä. Minä ymmärsin, että hän huomasi
- 71. jotakin yhtäläisyyttä kuvassa ja minussa, ja tietämättä syytä, tunsin tämän huvittavan ja liikuttavan mieltäni. "Aivan totta", sanoi isä, "hän on Pyhän Johanneksen näköinen." Lise taputti käsiään nauraen. "No niin", sanoi isänpä palaten esitykseensä, "mitä arvelet?" Koti! Minullako olisi koti! Kuinka monta kertaa tämä niin suloinen uni oli haihtunutkaan: Barberinin emännän, rouva Milliganin, Vitaliksen, kaikki nämä olin toisen toisensa jälkeen menettänyt. Minä en enää olisi yksin. Tilani oli kauhistuttava: olin nähnyt miehen kuolevan, jonka kanssa olin elänyt useampia vuosia ja joka minulle oli ollut melkein kuin isä; samalla olin menettänyt kumppanini, toverini, ystäväni, hyvän ja rakkaan kelpo Capin, josta niin pidin ja joka myös piti minusta. Mutta samalla kuin puutarhuri esitteli jäämistäni hänen luokseen, tunsin taas luottamusta. Ei siis vielä ollut kaikki lopussa minulta: elämä voi taas alkaa uudelleen. Enemmän kuin varma toimeentulo, joka oli minulle vakuutettu, ilahutti mieltäni tämä perhe-elämä, jonka osallisuuteen minäkin pääsisin. Nämä pojat olisivat veljiäni. Tämä kaunis pieni Lise olisi sisareni. Lapsellisissa mielikuvituksissani olin monet monituiset kerrat kuvaillut löytäväni äitini ja isäni, mutta en koskaan ollut ajatellut veljiä ja sisaria. Ja tässä ne nyt olivat tarjolla. Tosi on, että he eivät olleet oikeita veljiäni ja sisariani lihan ja veren kautta, mutta heistä voi tulla veljiäni ja sisariani ystävyyden kautta: sitä vartenhan ei
- 72. tarvinnut kuin rakastaa heitä (johon minä olin hyvin taipuisa) ja laittaa niin, että he rakastavat minua, joka ei tuntunut vaikealta, kun kaikki näyttivät olevan niin hyväluontoisia. Minä kiireesti laskin harpun olaltani. "Kas siinä vastaus", sanoi puutarhuri. "Pane harppusi tuohon naulaan, poikaseni, ja jos ei ole mieleistäsi luonamme olo, niin ota se sieltä milloin hyvänsä ja lennä pois. Sen vain huomautan, että tee niinkuin pääskyset ja satakielet: valitse sopiva aika lähteäksesi matkailemaan." Talon isännän nimi oli Acquin. Perheeseen kuului viisi henkeä: isäntä, jonka nimi oli isä Pierre, kaksi poikaa: Alexis ja Benjamin, kaksi tyttöä: Etiennette ja nuorin kaikista lapsista, Lise. Lise oli mykkä, mutta ei syntymästään; mykkyys ei ollut seuraus kuuroudesta. Kaksi vuotta hän oli puhunut, mutta sitten yhtäkkiä vähää ennen kuin täytti neljä vuotta, hän oli menettänyt puhelahjansa. Tämä tapaus, joka oli seurannut kouristustautia, ei onneksi ollut ehkäissyt hänen sielunkykyjään kehittymästä, vaan nämä päinvastoin olivat kypsyneet hyvin joutuisasti. Hän ymmärsi kaikki, mutta hän myöskin lausui, selitti kaikki. Kaikki häntä rakastivat, vanhempi sisarensa Etiennette häntä jumaloi. Rouva Acquin oli kuollut Lisen ollessa vuoden vanha, ja tästä päivästä aikain Etiennette oli perheen äiti. Kouluiällään täytyi hänen olla kotona, valmistaa ruoka, korjata isänsä ja veljiensä vaatteet ja kantaa Liseä käsivarrellaan. Kantaessaan Liseä käsivarrellaan, taluttaessaan Benjaminia, tehdessään työtä koko päivän, noustessaan varhain aamulla keittämään isälle ennenkuin tämä meni kaupalle, pannessaan myöhään maata, järjestettyään kaikki illallisen
- 73. jälkeen, pestessään lasten vaatteita, kastellessaan ryytimaata kesällä, noustessaan talvella keskellä yötä sytyttämään tulta, kun pakkanen kiihtyi kovaksi, alituiseen kovassa työssä ollessaan ei Etiennettellä ollut aikaa leikkimään lasten tavoin. Neljäntoista vuotiaana hänen muotonsa oli surullinen, vaikka siinä näkyikin lempeyden ja kieltäymyksen loiste. — Tuskin oli viittä minuuttia kulunut siitä, kun olin pannut harppuni naulaan, ja ollessani kertomassa miten kylmä ja väsymys meidät oli yllättänyt palatessamme Gentillyyn, jossa olimme toivoneet saavamme yösijan louhoksessa, niin kuulin raaputettavan ovea ja samalla iloista haukuntaa. "Se on Capi!" sanoin nousten vikkelästi. Mutta Lise ehti ennen minua avaamaan oven. Capi syöksyi yhdellä hyppäyksellä luokseni, ja kun minä otin sen syliini, niin se nuoleskeli kasvojani vinkuen iloisesti, ja koko sen ruumis vapisi. "Entäs Capi?" kysyin. — "No Capi jää sinun luoksesi." Aivan kuin olisi ymmärtänyt, hyppäsi se maahan, pani oikean käpälänsä rinnalle ja tervehti. Se nauratti lapsia, varsinkin Liseä, ja huvittaakseni heitä käskin Capin näyttelemään jotakin ohjelmistostaan. Mutta se ei totellut, vaan hyppäsi syliini ja alkoi taas nuolla kasvojani. Sitten hypättyään maahan se veti minua takkini hihasta. "Se tahtoo minua ulos." — "Viedäkseen sinut isäntäsi luo." Poliisipalvelijat, jotka olivat vieneet Vitaliksen, olivat sanoneet tarvitsevansa puhutella minua ja tulevansa päivällä, kun minä olen saanut lämmitellä ja nukkua. Tuntui pitkältä odotella heitä. Minä olin
- 74. levoton odottaessani tietoja Vitaliksesta. Ehkä hän ei olekaan kuollut, niinkuin oli luultu? Enpähän minäkään ollut kuollut. Hänkin on voinut virota niinkuin minäkin. Isäntä nähdessään minun levottomuuteni ja arvaten syyn siihen vei minut poliisivahtikonttoriin, jossa minulta kysyttiin kysymästä päästyäkin. Mutta minä en ruvennut vastaamaan, ennenkuin minulle vakuutettiin, että Vitalis oli kuollut. Minä kerroin sitten hyvin lyhyesti, mutta komisarius tahtoi aina vain enemmän tietää Vitaliksesta ja minusta. Itsestäni kerroin, ettei minulla ollut vanhempia ja että Vitalis oli minut vuokrannut ja maksanut vuokrasumman etukäteen kasvatusäitini miehelle. "Entäs nyt?" kysyi komisarius. Isäntä ehätti vastaamaan: "Me pidämme huolta hänestä, jos sen suvaitsette." Komisarius hyvin toki suvaitsi sen ja kiitteli puutarhuria hänen hyvyydestään. Nyt oli tehtävä selkoa Vitaliksesta ja se oli sangen vaikeaa, sillä minä en tiennyt hänestä isosti mitään. Oli kuitenkin muuan salaperäinen kohta, josta minä olisin voinut puhua, nimittäin se, mitä oli tapahtunut viimeisessä näytännössämme, kun Vitalis lauloi sillä tavoin, että herätti ihailua ja ihmetystä tuossa naisessa; sitten myöskin Garofolin uhkauksista, mutta minä tuumailin mielessäni, että tulisi pitää salassa nämä seikat. Pitikö tulla ilmi isäntäni kuoleman jälkeen se, mitä hän eläissään oli niin visusti salannut! Lapsen on vaikea salata mitään poliisikomisariukselta, joka on tottunut ammattiinsa. Nämä miehet osaavat tiedustella teiltä sillä
- 75. tavalla, että pian erehdytte salaamisessanne. Niin kävi minunkin. Viiden minuutin kuluttua tiesi poliisikomisarius sen, minkä minä olin päättänyt salata ja minkä hän halusi saada tietää. "Hänet on vietävä Garofolin luo", sanoi hän muutamalle poliisipalvelijalle. "Louroine-kadulle päästyään hän kyllä tuntee talon. Te menette hänen kanssaan ja kyselette Garofolilta." Me lähdimme kolmikannassa matkaan, poliisipalvelua, isä Pierre ja minä. Ja niinkuin poliisikomisarius oli sanonutkin, oli minun helppo tuntea talo, ja me nousimme neljänteen kerrokseen. Mattia ei ollut siellä, hän varmaankin oli päässyt sairashuoneeseen. Nähdessään poliisipalvelijan ja tuntiessaan minut Garofoli kalpeni. Häntä varmaankin pelotti. Mutta hän sai pian rohkaistuksi mielensä, kun hän poliisipalvelijan suusta sai kuulla, mitä varten olemme hänen luonaan. "Vai niin, vai on se ukko Vitalis kuollut", sanoi hän. — "Te tunsitte hänet?" — "Täydellisesti." — "No niin, kertokaa minulle mitä hänestä tiedätte." "No se on helppoa. Hänen nimensä ei ollut Vitalis, vaan Carlo Balzani, ja jos te olisitte elänyt kolmekymmentäviisi tai neljäkymmentä vuotta sitten Italiassa, niin tämä nimi riittäisi teille ilmoittamaan, mikä mies hän oli. Carlo Balzani oli tähän aikaan kuuluisin laulaja Italiassa, ja hänen esiintymisensä suurilla näyttämöillä olivat loistoisia; hän on laulanut kaikkialla, Napolissa, Roomassa, Milanossa, Venetsiassa, Florensissa, Lontoossa, Parisissa. Mutta sitten hän menetti äänensä, ja kun hän ei enää voinut olla taiteensa kuningas, niin hän ei tahtonut menettää kunniaansa esiintymällä pienemmillä näyttämöillä. Hän muutti nimensä Vitalikseksi salaten itsensä kaikilta, jotka olivat olleet hänen tuttujaan
- 76. hänen kunniansa päivinä. Mutta hänen oli kuitenkin elettävä. Hän koetti useampia elinkeinoja onnistumatta, niin että hän viimein monien vararikkojen jälkeen rupesi koirain näyttelijäksi. Mutta kurjuudenkin päivinä säilyi hänen ylpeytensä, niin että hän olisi häpeästä kuollut, jos yleisö olisi saanut tietää kuuluisasta Carlo Balzanista tulleen koiranäyttelijän. Sattumalta minä sain tämän salaisuuden tietooni." Tällainen selitys tuli sille salaperäisyydelle, joka minua oli niin mietityttänyt. Carlo Balzani raukka, rakas Vitalis!
- 77. XVIII. Seuraavana päivänä oli isäntäni haudattava, ja puutarhuri oli luvannut viedä minut hautajaisiin. Mutta seuraavana päivänä en voinutkaan nousta vuoteeltani, sillä yön aikana sain kuumeen. Minusta tuntui, kuin olisi ollut tuli rinnassa ja että olin kipeä samalla tavoin kuin Joli-Coeur sen yön jälkeen, jonka hän vietti puussa majalla ollessamme lumituiskussa. Ja itse asiassa olinkin saanut ankaran keuhkotulehduksen vilustumisesta yöllä, jolloin isäntäni kanssa jouduimme eksyksiin ja tuohon onnettomuuteen. Tämä tautini saattoi minut tilaisuuteen oikein arvostelemaan Acquinin perheen hyväntahtoisuutta ja erittäinkin Etiennetten alttiuden laatua. Vaikka köyhissä perheissä ei olla halukkaita kutsumaan lääkäriä, niin minun tautini oli kuitenkin niin ankara ja pelottava, että minun suhteeni tehtiin poikkeus tästä säännöstä. Lääkärin ei tarvinnut paljonkaan tutkia, ennenkuin hän oli selvillä taudin laadusta. Heti hän selitti, että minut oli vietävä sairashuoneelle. Sehän, oli tosiaan hyvin yksinkertaista ja helppoa. Mutta sitä ei isä Pierre kuitenkaan hyväksynyt. "Kun hän on sairastunut meidän ovellamme eikä sairashuoneen, niin täällä hänet on hoidettavakin."
- 78. Turhaan lääkäri koetti taistella kaikenlaisilla hyvillä sanoilla tätä selitystä vastaan saamatta sitä kumotuksi. Minut oli hoidettava täällä, ja täällä minut hoidettiin. Ja kaikkien töittensä lisäksi Etiennette oli sairaanhoitajattarena, hoitaen minua lempeydellä ja säännöllisesti kuin koskaan mikään Saint-Vincent de Paulin sisar, aina valppaana ja kärsivällisenä. Kun hänen piti lähteä luotani taloustoimiinsa, niin Lise tuli hänen sijaansa, ja monta kertaa kuumeeni aikana minä näin Lisen sänkyni jalkopohjassa seisomassa katsellen minua levottomin silmin. Houreissani luulin häntä suojelusenkelikseni ja puhelin hänelle aivan kuin enkelille toiveistani ja haluistani. Tautini oli pitkällinen ja tuskaisa, oli monia käänteitä, jotka ehkä olisivat huolestuttaneet vanhempia, mutta jotka eivät lannistaneet Etiennetten kärsivällisyyttä eikä alttiutta. Monia öitä hänen täytyi valvoa luonani, sillä minä olin usein tukehtua, ja hänen veljensä Alexis ja Benjamin valvoivat myös vuoron perään. Vihdoinkin alkoi parantuminen, mutta kun tauti oli pitkällinen ja oikukas, täytyi minun odottaa kevään tuloa, ennenkuin voin mennä ulos. Silloin Lise, joka ei ollut vielä töissä, tuli Etiennetten sijaan, ja hän kuljetteli minua ympäriinsä. Puolen päivän aikaan, jolloin aurinko oli lämpimimmillään, me menimme ulos ja kuljeksimme hiljalleen käsi kädessä, Capi seurassamme. Sinä vuonna oli kevät lämmin ja kaunis, tai ainakin se sellaisena on pysynyt minun muistossani, ja sehän on sama asia. Retkillämme ei Lise tietystikään puhellut, mutta kumma kyllä emme tarvinneetkaan sanoja; me katselimme toisiamme ja ymmärsimme toistemme katseen, niin etten minäkään hänelle puhunut.
- 79. Vähitellen palasivat sitten voimat, ja minä voin ryhtyä puutarhatyöhön. Tätä olin ikävöiden odottanut, sillä minua halutti tehdä muille mitä muut olivat tehneet minulle, tehdä työtä heidän hyödykseen voimieni mukaan. Minä en ollut koskaan ollut työssä, sillä niin vaivalloisia kuin pitkät matkat ovatkin, ne eivät kuitenkaan ole jatkuvaa työtä, joka kysyy tahdon lujuutta ja ahkeruutta, mutta minusta tuntui, että minä kykenen tosityöhön, ainakin tunsin rohkeata halua niiden esimerkistä, jotka olivat ympärilläni. Kotikylässäni olin nähnyt maanviljelijöitä työssä; minulla ei ollut mitään käsitystä ahkeruudesta, sitkeydestä ja tarmosta, jolla Parisin ympäristön puutarhurit tekivät työtä, ollen toimessa auringon noususta sen laskuun ja kaiken aikaa raataen voimainsa perästä. Eikä minulla ollut tätä ennen ollut aavistustakaan siitä, miten työllä maa saadaan tuottavaksi. Olin nyt erinomaisessa koulussa. Niin väsyttävää kuin tämä uusi työ olikin, totuin kuitenkin pian tähän uutteraan elämään. Sen sijaan että ennen juoksentelin vapaana näkemättä muuta vaivaa kuin astuksia teitä, olin nyt suljettuna puutarhan muurien sisään, sain tehdä ankarasti työtä aamusta iltaan, paitaa myöten märkänä hiestä. Mutta jokainen teki työtä yhtä ankarasti, isännän kastelukannut olivat raskaammat kuin minun, hänen paitansa märempi hiestä kuin minun. Ja minullahan nyt oli se, mitä olin kaivannut: koti. En ollut enää yksin, en ollut hyljätty lapsi, minulla oli oma vuoteeni, minulla oli sijani ruokapöydässä, joka meidät kaikki yhdisti. Oli meillä sitten levon ja huvituksen hetkiäkin, tosin lyhyviä, mutta sitä hauskempia. Sunnuntaisin jälkeenpuolisten kokoonnuttiin pieneen viinimajaan, ja siellä minä soittelin harppuani, joka viikon ajan lepäsi rauhassa naulassa, ja talon tyttäret ja pojat tanssivat.
- 80. Kukaan heistä ei ollut oppinut oikein tanssimaan, mutta Alexis ja Benjamin olivat kerran olleet häissä ja sieltä he muistivat vähän kontratanssia, jota nyt tapailivat keskenään. Kun he väsyivät tanssimaan, niin minä lauleskelin laulujani, ja minun napolilainen lauluni teki aina haihtumattoman vaikutuksen Liseen. En kertaakaan laulanut niin, etteivät hänen silmänsä olisi kostuneet. Huvittaakseni sitten häntä näyttelimme jonkin näytelmän Capin kanssa. Capillekin nämä sunnuntait olivat juhlapäiviä; ne muistuttivat sille menneitä aikoja, ja kun se oli näytellyt osansa loppuun, se olisi tahtonut näytellä sen uudelleen. Näin kului kaksi vuotta, ja kun isä Pierre otti minut usein mukaansa torille ja muualle, niin opin vähitellen tuntemaan Parisin, joka ei tosin ollut marmorinen ja kultainen kaupunki, niinkuin olin sitä kuvitellut, mutta eipä se ollut lokakaupunkikaan, niinkuin se minusta oli näyttänyt tullessamme Charentonin ja Mouffetardin kaupunginosien kautta. Onneksi sain muutakin opetusta kuin sitä, mitä sattumalta näin retkilläni Parisissa. Isä Pierre oli ollut ennen puutarhuriksi rupeamistaan työssä luonnontieteellisessä puutarhassa, jossa hän oli saanut kaikenlaista opetusta. Ja sittemmin hän vuosien kuluessa oli hankkinut kirjoja, joita joutohetkinään viljeli ahkerasti. Naimisiin ja perheelliseksi tultua hänen joutohetkiensä luku supistui, kun elatuksen hankkimisesta oli suurempi huoli. Silloin kirjat olivat jääneet, mutta niitä ei kuitenkaan oltu myöty eikä hukattu. Ne olivat säilössä kirjakaapissa. Ensimäinen talvi, jonka vietin Acquinin perheessä, oli sangen pitkä, ja puutarhatyö useitten kuukausien aikana ei ollut kiireellistä. Silloin iltapuhteita viettäessämme tulen äärellä vedettiin kirjat säilöstään. Alexis ja Benjamin eivät olleet
- 81. perineet isänsä lukuhalua, ja he aina luettuaan muutamia sivuja nukahtivat. Minä kun en ollut niin unelias kuin utelias, luin sitävastoin siihen saakka kuin tuli makuullemenon aika. Vitaliksen opetus ei siis ollut mennyt hukkaan, ja aina kun menin levolle, muistelinkin häntä kaipauksella ja kiitollisuudella. Lise ei osannut lukea, mutta nähdessään minun tarttuvan heti kirjaan, kun minulla oli vähänkään joutoaikaa, hän pyysi minua lukemaan niitä hänellekin. Tämä oli uusi side välillämme. Ja kirjallisuudesta hän sai paremmin kuin keskustelusta huvia ja henkensä kehitystä. Minä opetin hänelle myöskin piirustusta, nimittäin sellaista piirustusta, jota itse osasin. Tietysti minä olin sangen huonokuntoinen opettaja, mutta me ymmärsimme hyvin toisemme, ja hyvä sopu opettajan ja oppilaan välillä vaikuttaa usein enemmän kuin taito. Mikä ilo syntyikään, kun hän osasi piirtää jotakin niin, että sen tunsi! Isä Acquin syleili minua. "Kas niin", sanoi hän nauraen, "minä olisin voinut tehdä suuremmankin tyhmyyden kuin sen, että otin sinut. Lise sitten myöhemmin maksaa sinulle." Myöhemmin — sitten kun hän saa puhelahjansa, sillä lääkärit olivat sanoneet, että hän ei ole sitä menettänyt kaikeksi iäkseen. Tätä nykyä ei voitu tehdä sille mitään, oli vain odotettava muutosta. Ja Lise itsekin teki surullisen liikkeen, joka merkitsi, että sitten myöhemmin hän korvaa, kun minä lauloin hänelle. Hän oli halunnut oppia soittamaan harppua, ja varsin pian hänen sormensa tottuivatkin matkimaan minun sormiani. Tietysti hän ei voinut oppia laulamaan, ja se häntä suretti. Monta kertaa näinkin hänen silmissään kyyneliä, jotka ilmaisivat hänen surunsa. Mutta hyväluontoinen ja lempeä kun oli, ei hänen surunsa kauan kestänyt;
- 82. hän kuivasi kyyneleensä, ja hymy hänen suupielissään sanoi minulle myöhemmin. Minä varmaankin olisin iäkseni jäänyt Acquinin perheeseen, jollei olisi sattunut muuan surullinen tapaus, joka yhtäkkiä taas muutti minun elämäni. Niin näytti sallitun, että minä en saa kauan olla onnellinen, ja että silloin kun olin varmin rauhallisesta elämästäni, olikin jo lähellä hetki, jolloin jouduin taas seikkailuelämän kuohuihin.
- 83. XIX. Oli sellaisia hetkiä, jolloin minä yksin ollessani tuumailin mielessäni: tämä on niin onnellista, että tätä ei voi kestää kauan. Minä en voinut aavistaa miten elämä voisi muuttua onnettomaksi, mutta minä olin siitä kuitenkin melkein varma, että se tapahtuu tavalla tai toisella. Se sai minut usein hyvin surulliseksi, mutta siitä oli kuitenkin se etu, että minä kaikin tavoin koetin tehdä parastani kuvaillen mielessäni, että minun hairaukseni kautta se onnettomuus minua kohtaa. Siihen ei kuitenkaan ollut minun syytäni, mutta sen näin vasta onnettomuuden tapahtuessa. Acquin viljeli kukkia. Sääntönä on, että puutarhurilla ei saa olla tilkkuakaan viljelemätöntä maata: heti kun toiset kukat on myyty, on toisia kylvettävä. Ja puutarhurin, joka on kauppapaikkain läheisyydessä, on kuljetettava kukkansa kaupaksi sellaisina aikoina, jolloin hänellä on toivoa saada niistä suurin tulo. Tällaisia aikoja ovat suuret juhlat ja erityiset nimipäivät. Ja tällaisina päivinä ovat Parisin kadut täynnä kukkia, sillä niitä kaupitellaan joka sopessa, mihin vain tavara voidaan asettaa nähtäväksi. Leukoijain jäljestä Acquin teki työtä heinäkuun ja elokuun juhlia varten, varsinkin elokuuksi, jolloin P. Marian ja P. Ludvigin päivät olivat, ja niitä varten meillä oli kasvamassa kukkia niin paljon kuin taimilavoihimme ja
- 84. kasvihuoneisiimme suinkin sopi. Ja kaikki kasvit piti saada kukalle juuri näiksi päiviksi, ei varemmin eikä myöhemmin. Voi hyvin ymmärtää, että tämä vaatii erityistä taitoa, sillä eihän ihminen ole auringon eikä ilmojen herra. Acquin olikin hyvin taitava kasvien hoidossa, niin että hänen kukkansa eivät joutuneet liian varhain eikä liian myöhään. Mutta siitäpä olikin työtä ja vaivaa! Tähän aikaan, jossa kertomukseni liikkuu, olivat kaikki merkit hyvät; meillä oli elokuun 5 päivä, ja kukat olivat umpulla ja reheviä. Acquin tuontuostakin hieroskeli käsiään tyytyväisenä. "Tulee hyvä sato", sanoi hän. Ja hymysuin hän teki laskuja, paljonko kaikki nämä kukat hänelle tuottavat, kun tulee kaupan aika. Kovasti oli tehty työtä lepäämättä tuntiakaan, edes sunnuntaisin. Kuitenkin sittemmin kun kaikki oli hyvässä järjestyksessä ja työ kaikki tehty, päätettiin, että me tänä sunnuntaina, elokuun 5 päivänä, palkkioksi työstämme lähtisimme päivällisille Arcueiliin muutaman Acquinin ystävän luo, joka niinikään oli puutarhuri. Työtä tehtäisiin kolmeen tai neljään päivällä, ja sitten kun kaikki olisi suoritettu, suljettaisiin portti ja lähdettäisiin matkalle, niin että tultaisiin Arcueiliin viiden tai kuuden aikana, sitten päivällisen jälkeen palattaisiin heti, että jouduttaisiin aikoinaan levolle ja maanantaina varhain työhön raittiilla voimilla. Niin oli päätetty, ja muutamia minuutteja ennen neljää isä Acquin lukitsi suuren portin. "Eteenpäin koko joukko!" huusi hän iloisesti, "Capi edelle!" Minä tartuin Liseä kädestä, ja me juoksimme yhdessä Capin iloisesti haukkuessa ympärillämme.
- 85. Molemmat olimme hyvin sunnuntaisen näköisiä kauniissa kyläpuvuissamme. Ihmiset kääntyivät meitä katsomaan. En tiedä katsoivatko minua, mutta sen tiedän, että Lise olkihattu päässä, sininen hame yllään, harmaat vaatekengät jalassa, oli mitä ihanin pikku tyttö. Hänen vilkkaudessaan oli suloa, hänen silmänsä, väräjävät sieraimensa, olkapäänsä, käsivartensa, kätensä, kaikki hänessä puhui ja ilmaisi hänen sulouttaan. Aika kului ihan huomaamatta. En muuta tiedä kuin että lopetellessamme päivällistä joku meistä huomasi mustia pilviä länsitaivaalla, ja kun ruokapöytämme oli ulkona suuren seljapuun alla, niin oli helppo jokaisen nähdä, että myrsky oli tulossa. "Lapset, nyt joutuin kotia." Syntyi yleinen hämmästys, ja yhteen ääneen huudahdettiin: "Nytkö jo!" "Jos tuuli nousee", sanoi isä, "niin se voi tehdä tuhon. Taipaleelle heti." Siinä ei ollut enää vastustamista. Jokainen meistä tiesi, että lasikatot ovat puutarhurin omaisuus, ja jos myrsky ne särkee, niin se on puutarhurin häviö. "Minä, Benjamin ja Alexis menemme edellä. Remi tulee Etiennetten ja Lisen kanssa jäljestäpäin." Ja he lähtivät pitkin askelin, jotavastoin me kuljimme hitaammin, sen mukaan kuin Lise ehti. Emme enää nauraneet emmekä hyppineet. Taivas synkistyi synkistymistään, ja myrsky lähestyi joutuisasti ajaen edellään pölypilviä, joita tuuli kiersi ilmaan pyörteinä. Kun
- 86. tällainen tuulispää sattui kohti, niin piti ehdottomasti pysähtyä, kääntyä selin tuuleen ja peittää silmänsä käsin, muuten olisi saanut ne soraa täyteen. Kaukana jyrisi ukkonen nousten rajusti. Etiennette ja minä pidellen Liseä kädestä vedimme häntä jäljessämme, mutta hänen oli vaikea seurata meitä, joten emme päässeet niin kiireesti kuin olisimme halunneet. Ukkonen jyrähteli tiheämpään, ja pilvet olivat käyneet niin paksuiksi, että oli pimeä melkein kuin yöllä. Ukkosen jylinän seasta alkoi kuulua omituista pauhua, josta emme ensin tienneet mitä se oli. Mutta sitten yhtäkkiä alkoi sataa rakeita, ensin muutamia, jotka löivät kasvoihimme, ja sitten aivan kuin kaataen, niin että meidän piti hakea suojaa muutamasta porttikäytävästä. Ja nyt tuli niitä hirvittävästi. Silmänräpäyksessä katu oli valkeanaan aivan kuin sydäntalvella. Rakeet olivat kyyhkysenmunan kokoisia ja tulivat sellaisella pauhulla, että korvat olivat mennä lumpeeseen. Pauhuun yhtyi särkyvien akkunain sälinä ja räminä. Katoilta putoilevien rakeitten seassa tuli kaikenlaista muuta, tiilikivenpalasia, kipsilohkareita, vuolukivilaattoja, jotka näyttivät mustilta pilkuilta valkoisessa raejoukossa. "Meidän lasikatokset!" huudahti Etiennette. Sama ajatus tuli minunkin mieleeni. "Ehkä ovat ehtineet ajoissa kotia." "Vaikka olisivatkin ehtineet ennen raesadetta, niin eivät kuitenkaan ole saapuneet niin ajoissa, että olisivat saaneet lasit peitetyiksi oljilla. Kaikki on mennyttä."
- 87. "Sanotaan, että raesade kulkee paikoittain." "Me olemme niin lähellä kotia, että kyllä sielläkin sataa, ja jos siellä sataa niinkuin tässäkin puutarhaan, niin voi isä raukkaa! Hän laski niin suuren saaliin saavansa ja olisikin tarvinnut kaikki ne rahat!" Tuntematta hintoja olin kuitenkin usein kuullut sanottavan, että lasilliset kasvilavat maksoivat 1500 tai 1800 markkaa sata, ja ymmärsin heti mikä häviö olisi meille, jos rakeet särkisivät viisi-, kuusisataa katostamme. Minä ajattelin kysyä Etiennetteltä, mutta huomasin sen turhaksi, sillä emme olisi kuulleet enää toistemme ääntä, kun raesade piti sellaista pauhua, ja sitäpaitsi hän ei näyttänyt olevan ollenkaan halukas puhelemaan, vaan katseli raesadetta niin lannistuneen näköisenä kuin ihminen, joka näkee talonsa palavan. Tätä kauheaa sadetta ei kestänyt kauan, viisi tai kuusi minuuttia, ja se lakkasi yhtä äkisti kuin oli alkanutkin. Pilvet kiitivät yli Parisin, ja me lähdimme suuren portin suojasta. Kovat ja pyöreät rakeet vyöryivät kadulla jaloissa aivan kuin somero meren rannalla, ja niitä oli nilkkaa myöten. Kun Lise vaatekengissään ei voinut kulkea tällaista raetietä, niin minä otin hänet selkääni. Hänen muotonsa, jolla tullessamme ilo loisti, oli nyt surullinen, ja kyyneleet vierivät hänen silmistään. Kiireesti kuljimme kotia. Suuri portti oli jäänyt auki, ja me ehätimme puutarhaan. Mikä näky! Kaikki oli sirpaleina ja runneltu: lasinsirpaleet, rakeet ja kukat yhtenä sotkuna. Kauniista puutarhasta, joka aamulla oli niin rikas, ei ollut jäljellä kuin nämä nimettömät korret. Missä oli isä?
- 88. Me etsimme häntä, kun emme missään nähneet, ja tulimme suureen kasvihuoneeseen, josta ei ainoatakaan lasia, ollut jäänyt eheäksi. Siellä hän istui lyykistyneenä jakkaralla keskellä korsia, jotka peittivät maan, ja hänen vierellään Alexis ja Benjamin liikkumattomina. "Voi lapsi raukat!" huudahti hän kohottaen päätään meidän lähestyessämme, jonka hän huomasi, kun lasinsirpaleet raskivat jaloissamme. "Voi lapsi raukat!" Ja hän otti Lisen syliinsä ruveten itkemään sanaa sanomatta. Mitä hän olisi voinut sanoakaan? Tämä oli vahinko, silminnähtävästi suuri vahinko, mutta sen seuraukset olivat vielä kauheammat. Etiennetteltä ja hänen veljiltään sain pian tietää, että isä oli syystä epätoivoissaan. Kymmenen vuotta sitten hän oli ostanut tämän puutarhan ja oli itse rakennuttanut talon. Maan myöjä oli hänelle samalla lainannut rahaa tarpeitten ostoa varten. Kaikki oli takaisin maksettava viidessätoista vuodessa vuosittain. Tämä säännöllinen maksaminen oli sitä välttämättömämpi, kun velkamies odotti vain tilaisuutta ottaakseen maan ja talon ja tarveaineet, pidättäen tietysti kymmenen vuoden maksutkin, jotka jo oli saanut. Se oli velkamiehen tarkoitus, niin oli huomattu. Hän toivoi, että kai viidessätoista vuodessa kerran sattuu niin, ettei Acquin voikaan maksaa vuosimaksuaan. Tämä päivä oli nyt tullut, sen tuotti raesade. Mitä nyt oli tapahtuva? Sitä meidän ei tarvinnut kovinkaan kauan odottaa. Jo heti sitä seuraavana päivänä, jolloin Acquinin olisi pitänyt suorittaa vuosimaksunsa ja jonka hän, jos ei onnettomuus sattunut, olisi suorittanutkin tuloillaan kukkakaupasta, ilmestyi taloomme mustiin
- 89. puettu mies, joka ei ollut kovin kohteliaan näköinen ja joka antoi karttamerkillä varustetun paperin, mihin hän kirjoitti muutamia sanoja. Hän oli oikeudenpalvelija. Acquin ei enää pysynyt kotona, vaan kävi myötäänsä kaupungilla. Mitä hän siellä teki? En tiedä, sillä hän, joka ennen oli niin puhelias, ei enää virkkanut sanaakaan. Hän varmaan kävi oikeudessa. Tämä ajatus sai minut kauhistumaan. Vitalis oli myöskin ollut oikeudessa, ja minä tiesin mikä siitä oli seurauksena. Tällä kertaa ei seuraus ollut niin pikainen. Kului hyvä osa talvea. Eräänä iltana tuli sitten isä kotia masentuneempana kuin koskaan ennen. "Lapseni, nyt se on päättynyt!" sanoi hän. Minä yritin lähteä ulos, arvellen että nyt oli edessä vakava kysymys, ja kun hän oli kääntynyt suorastaan lapsiensa puoleen, niin tuntui minusta, että minun ei sopinut kuunnella. Mutta hän esti minut menemästä. "Olethan sinäkin meidän perhettämme", sanoi hän. "Ja vaikka olet vielä nuori, niin olet kuitenkin saanut kokea niin paljon, että ymmärrät asian merkityksen. Lapset, minun täytyy erota teistä." Kuului huudahdus, yhteinen tuskan huuto. "Te ymmärrätte, ettei mielellään jätä niin hyviä lapsia kuin te olette, sellaista rakasta pientä raukkaa kuin Lise." Ja hän sulki Lisen syliinsä. "Minut on tuomittu maksamaan, eikä minulla ole rahaa. Ja kun minulla ei ole rahaa, niin kaikki täältä myydään. Mutta kun se ei riitä, niin minut pannaan vankeuteen viideksi vuodeksi. Kun en voi rahalla maksaa, niin minun täytyy maksaa ruumiillani, vapaudellani."
- 90. Welcome to our website – the perfect destination for book lovers and knowledge seekers. We believe that every book holds a new world, offering opportunities for learning, discovery, and personal growth. That’s why we are dedicated to bringing you a diverse collection of books, ranging from classic literature and specialized publications to self-development guides and children's books. More than just a book-buying platform, we strive to be a bridge connecting you with timeless cultural and intellectual values. With an elegant, user-friendly interface and a smart search system, you can quickly find the books that best suit your interests. Additionally, our special promotions and home delivery services help you save time and fully enjoy the joy of reading. Join us on a journey of knowledge exploration, passion nurturing, and personal growth every day! ebookbell.com