Сайт проектной организации Челябэнергопроект на русском языке   Русский
Main To write the mail Map
Die Web-seite der Projektorganisation Tscheljabenergoprojekt in Deutsch   Deutsch

Création de site web société française Chelyabenergoproekt   Française

Projects intellectual skill!
Our News
12/22/2016 Happy New Year!
Happy New Year! Administration ...
12/30/2015 Happy New Year!
Happy New Year! Administration ...
12/21/2015 Happy Energy!
Happy Energy! Administration ...

News of branch
объекты Ростехнадзора
Features of safety at interaction between design works in the Internet
Today set of Internet tools co-operate with each other through the Internet. A special class of interactions – in what transmission of the confidential information (the personal data, confidential messages is carried out) or the commands which performance should be unambiguously confirmed by someone (for example, remittance or the publication of the message from someone's name). It is obvious that similar tools should be reliably protected from malefactors.

Unfortunately, not all developers reflect on a degree of security of the applications. The problem is a little aggravated with that many representatives of electronic business develop protocols which, being realised in finite tools, can create serious vulnerability if to use them without due understanding.

The task of given article – short to describe possible types of attacks at interdesign (i.e. A server-server) interaction and protection frames from them – more thoughtfully to use ready protocols and to develop the. Bases of informational safety as frequently knowledge of finite developers in this area happens a little sketchy will be preliminary considered.

Protection (or absence of protection) from various types of attacks is shown on an example of protocols of systems popular today: Assist, Cyberplat, WebMoney, ChronoPay, Robokassa and PayPal (payment systems), and also OpenID, OpenAuth, OAuth (the decentralised authentification).

Let's consider concept of safe interaction.

So, let's be defined that we mean by words “safe interaction”:
1. authentification. Let the server A wishes to transfer the message to a server B. Should have possibility to check up that the message is sent from A. The given check is named as authentification of a server A on server B.
2. Data integrity. We wish to be assured that the message by transmission has not been changed (for example, has been paid 50$, and the confirmation is received on 500$).
3. confidentiality of interaction. The given item means that the message is received only by those sides which have on this right. As a rule, the given item means enciphering information by transmission. In certain cases it is possible to consider two more items: check of access rights and impossibility of refusal of authorship (non-repudiation), but now we will lay it aside.

For consideration cryptography primitives interested persons can pass under references to Wikipedia and receive particulars.

Let's consider disadvantages SSL/TLS and HTTPS.

Us not always arranges SSL/TLS:
- Complexity of check of authenticity of any server in an application code. As consequence – partial usage of the protocol, without protection against attack “The person in the middle”.
- One-sided authentification (yes, there are modifications of the protocol for double-sided, but it is used less often, and not for all programming languages it is easy to find ready solution).
- Besides, SSL/TLS architecture does not allow to save the message with the digital signature of the remailer later to use it for that proof that the message has really been sent by the author (i.e. Protection against refusal against authorship) does not work.

Let's consider safety implementation in practice:

1. For authentifications use usually or to steam “a login – the password” or the digital signature generated by that or other method.
2. For check data integrity use SSL/TLS and digital signatures formed by the application.
3. For encodings the data, that is confidentiality supports use the majority of systems SSL/TLS (there are examples of independent enciphering of keys, however the data cipher “its” methods rather seldom).

Speaking about web tools, more often SSL/TLS use in the form of HTTPS.

Let's consider types of protected applications.

Before, at last, passing to attacks to protocols, it is necessary to tell about limitations in which the projected system works. It is necessary to mention three main types of applications for which it is possible to consider questions of safe interaction:
1. Two co-operating sides have possibility in advance to exchange on guaranteed to the protected channel the necessary information: internal transmission of the necessary information between people can be the common key, certificates, passwords and so forth Such channel (is better), an alternative data link (cellular communication, phone) or even the Internet – if both sides are assured of absence “The person in the middle” or other way of interception or message modification.
2. Centralised architecture. Each two sides have no possibility to agree with each other in advance, but any participant of a network trusts some third party which signs certificates of the co-operating sides and guarantees them validity. As an example it is possible to name an infrastructure of open keys (Public Key Infrastructure, PKI) or, with some stipulations, the same Internet in which browsers trust a finite number of certified centers, and on the basis of it can be convinced that they co-operate with the necessary site.
3. Decentralised architecture. In similar applications there is no uniform third party. It is important to understand that of similar architectures the primary goal – to be convinced that in the second time to you the same person has come that came earlier. That is, for the first time you allow to pass authentification to everybody (for example, on the sites supporting OpenID, any can take place authentification). Let further you have made any contribution to system: for example, have written the message. When you will come here next time, the site should give you (and only to you) access to editing of this message. Examples of protocols: OpenID, OAuth, Peer-to-Peer protocols.

Let's consider attacks and ways of protection.

1. Absence of check of authorship or authenticity of the message.

I will dare to recollect an old joke. In programming exists two types of errors: absence of check of input data – and all other errors.

If to you the message of M from the side And it is necessary to be convinced that has come: the message has really come from And; that And referred the M message, and it has not been changed on the way.

Example of illiterately designed protocol is the protocol of interaction of payment system Assist with Internet shop. After purchase payment on a server of Assista, the user comes back to some URL_RETURN_OK address which is transferred in open sort and can be updated the user-buyer. That is, the user comes back after purchase payment in our Internet shop, to it speak: “Thanks, you have just paid payment for the sum 1000$” – but the shop does not have absolutely any possibility to be convinced that it is real so. Only later, hands of the manager or it is automated (but not more often 1 time 10 minutes!) it is possible to check up that payment has really passed. The protocol of Assista, by the way, was not updated already more than 4 years. And only it is necessary – to add the digital signature.

So, how carry out check of authorship and integrity of the message.
- Use digital signatures on base of pair from a confidential and open key. Possibly, it is the most reliable and universal (i.e. Working in any conditions) a way. The open key can be transferred to a receiving party in advance (a similar way use today WebMoney, Cyberplat, OAuth and many other things). Also the open key can be received later on not protected connection and is checked up by means of the certificate of certified center (Certification Authority, CA). This way underlies functioning of an infrastructure of open keys (Public Key Infrastructure, PKI), used in the large companies.
- Form the common key To – for example, on the basis of Diffie-Hellman protocol or similar and use it for underwriting of messages (for example, with usage HMAC-SHA1). It is used in OpenID.
- If to us integrity of the message is not important, and the confirmation of authorship is important only, sometimes use pair “a login – the password” or confidential string for access to the protected resource. For example, Flickr gives photos on XML-RPC protocol in reply to the inquiry containing a login and the password. The system reCAPTCHA allows to check up a CAPTCHA-code entered by the user, authenticating of checking on confidential string. It is necessary to understand that this way though it is simple, extremely bad that message interception opens your password, and further the malefactor can freely send inquiries from your name. In case of usage of the digital signature interception of the message will allow to make nothing to the malefactor.
- There is more simple (though and not protected from attacks of substitution of a server and “The person in the middle”) a way of check of authenticity of the message. For example, PayPal in the Instant Payment Notification (IPN protocol obliges the server accepting confirmation about spent payment, to send a message copy back on a server with a question “whether really you to me dispatched it”? The similar way is used in OpenID protocol (the truth, by operation in an unrecommended mode), only is back referred not simply the message, and the message with the digital signature, and the inquiry looks already as “check up, whether you appended this digital signature”. The similar circuit works and in OpenAuth. Advantage of the approach it is possible to consider to realise absence of necessity cryptography algorithms with one or from two sides.
- Robokassa has thought up the original way of creation of the digital signature: the digital signature is formed as hashing function MD5 from the message and the confidential password. It is necessary to concern the given way with care at least because the password should be reliable enough. If the password short, and, especially, if it is selected by the person, decryption of your password can appear the simple task for a hacker.

2. Hope of reliability HTTPS.

As realisation within the limits of the HTTPS-report of authentification of any server to which your application is connected has been specified above, – the challenge is enough. Above we considered details short output from which is simple: without check of authenticity of the certificate of a server sense HTTPS can be lowered to zero. Any of protocols of the decentralised authentification – whether it be OpenID, OpenAuth, OAuth, is not protected from attack of substitution of a server or “The person in the middle”. In certain cases (PayPal, Assist) it is possible to attack payment systems in the similar way. As a result, you can convince the application of Internet shop that there was a payment though actually it was not.

Let's underline once again that it is possible to be protected from this attack, if the server installing HTTPS-connection possesses enough of certificates of cores CA of the Internet (VeriSign, COMODO etc.), but in practice it is sometimes difficult realised.

Also we will underline that for the decentralised systems it essentially insoluble problem. While for the commercial payment systems concerning on our classification (see above) to the systems which sides can “in advance to agree” the given attack is warned by competent designing of the protocol. The example of similar implementation shows WebMoney, the giving certificate for check of authenticity of HTTPS-connection. 3. Attack “The person in the middle” (Man in the Middle, MITM).

We have considered attack MITM for HTTPS protocol. However, other protocols also can be vulnerable for of this kind attacks. The example to that is Diffie-Hellman, used in OpenID. As it was specified above, its essence in generation of the common key To two sides: And and B.No if for us is someone “in the middle” () who can change the traffic it can appear so that And has generated the common from M key K1, and – the common from M key K2. As a result “The person in the middle”The M can sign and read any data going in any direction.

Certainly, similar attack will not pass in OpenID if the client and a server (OpenID Provider and Relying Party) co-operate on HTTPS with high-grade check of the certificate.

4. Private key transmission on the open channel.

Many developers do not understand a private key essence. All safety in an infrastructure with usage of an open key is constructed that the co-operating sides can unconditionally trust someone. To the second server, the third party – it is not important. As a rule, a question “confidence” rests against check of the digital signature with usage of an open key of the subscriber of the message. All safety can fail, if this open key (certificate) is transferred on not protected channel and can be on the way updated.

In “serious” the companies there are the special people who are responsible for transmission, storage, upgrade of this key. Transmission usually occurs in “an offline” through reliable couriers.

If you create the protocol for payment system, transmission of an open key of your server personally in hands to the owner of Internet shop (on a diskette or flash drive) is ideal at contract signing at office. Yes, for whatever reasons it not always really to carry out. Therefore the certificate often extend through the Internet. But in this case it is necessary to take all possible measures on preventing of substitution of a key. It is impossible to send a key by e-mail. It is impossible to allow to download it on HTTP – only HTTPS. On a site the information on check downloaded information (for example, hash from a key for check of its authenticity) should be placed.

5. Repeated sending of inquiry.

We will consider the given sort of attack on two examples.

Example 1: payment system. Let I, a respectable server, wish to send 10$ through payment system. Thus for connection with a server payment systems I use HTTP or “bad” HTTPS (without certificate check). I fairly form inquiry and I sign its certificate. Other side receives inquiry, and I 10$ leave to a target. But as I used the open protocol, the malefactor could read my inquiry to a server. If this malefactor wishes me to ruin, it takes and sends the same inquiry to a server of payment system once again. The server checks the signature (it true as it is generated “correct” a server), and others 10$ are written off from my score. Example 2: OpenID protocol. In OpenID Authentication 1.1 protocol there was a following vulnerability. If the malefactor listened to interaction of the OpenID-client (Relying Party) and the end user, it could initiate through any time repeated authentification of this user on Relying Party with its usage OpenID. In this case in broad gulls Relying Party there would be a record that the person came on a site. The malefactor could even pass authentification in especially thoughtless cases of implementation under a name of this user. Yes, against it there are ways of protection, but they have not been declared as mandatory in the protocol.

The given vulnerability have eliminated in version OpenID Authentication 2.0, having entered changes into behaviour as server (OpenID Provider), and the client (Relying Party). To the readers familiar with OpenID Authentication protocol, I offer a problem on understanding: how to realise similar protection in OpenID client of version 1.1 if a server to update there is no possibility?
For protection from of this kind attacks there are next ways:
- Cyberplat, for example, obliges the clients to insert into each inquiry unique number of session. Such unique number name also as a word nonce (Number used ONCE). With identical number of session the payment system will simply refuse to handle two inquiries. And change number of session the malefactor cannot, as it has no possibility to generate the correct digital signature for the changed message.
- It is possible to use also protection on time, inserting into inquiry a label with current time. “old” inquiries are cut.
- OpenID 2.0 uses both these of a method for protection from of this kind attacks: nonce includes current time and (optionally casual string.

6. For entirety of the description it is necessary to mention also banalities. If the system is constructed on privacy of the password or a key this data should be reliably protected. Exhibiting of UNIX-privileges 07ХХ on access to all files on a Shared-hosting can be completed by that a file of the certificate or the password to a DB where are stored “secrets” will read “the neighbour in a server”. It is not necessary to forget to expose passwords, privileges, to differentiate access. However, I will long not extend, as all know it (though, not all do).

7. One more sort vulnerabilities – that form by programmers at protocol implementation. I will result one simple example (fortunately, not being how many serious vulnerability): 2 years ago in two of five most popular implementations of an OpenID-server developers have confused concepts life_time (time of a life of a key in seconds) and expires_time (time of the expiration of a key in seconds from January, 1st 1970). Especially critical sites of a code it is desirable to subject to review by other participants of the project (ОК, it too banality? – Then we will pass to the conclusion).

Let's consider ten most widespread errors in sphere of computer safety which in no event cannot be made:
1. Sending of the confidential data in non-encoded electronic letters. Is not admitted to send passwords, personal handles and the data of accounts in non-encoded electronic letters.
2. Usage “check” questions the answer on which is easy for guessing. Insurance number, a maiden name of mother, a name of the house pupil, a date of birth – all it is not a well-tried remedy of identification of the person. Usage such “check” questions for restoring of the password of the end user does the password almost useless because any who has time and desire, can pick up in that case with ease a key to another's account.
3. Usage of too strict limitations on a password choice. We should face often control systems of the finance online (Internet banking type) which instal such strict limitations on a password choice that security of the interface from it only decreases. Passwords from six digits are popular.
4. Blind confidence in safety issues to manufacturers of the software. Software suppliers which can be trusted unconditionally, simply do not exist. Eventually, the only thing that interests manufacturers is their own profit and a share in the market. Sometimes it really induces them to strengthen safety of the software products and services, but occasionally – absolutely on the contrary. Therefore definition “reliable safety” from a software supplier always it is necessary to call into question. Do not allow to decide to manufacturers for you that for you it is more important.
5. Misunderstanding of that, professional experience in safety sphere is how much important. Heads of corporations (and technical grounded IT-experts including) often do not give a proper attention to a problem of professionalism in the field of safety. Reaches that research groups on development of standards of safety include many talented programmers and any expert in cryptography (as it was in a case with WEP) – besides that they try to create the standards leaning directly on encryption algorithms.
6. Misunderstanding of that, independent check is how much important. Even on specific sorts of safety the same experimental experts should check operation of experts. In safety sphere mutual checks – something like sacred Graal absolute protection, and no system can be considered safe until will be carefully and is deeply tested by the experts not involved in its development.
7. Excessive care of privacy. Many software developers in sphere of safety not only underestimate importance of independent check, but also overestimate the significance of privacy. They prove the refusal to send operation on check to those independent experts that the most important thing is to keep a security policy a secret. Meanwhile, as says a principle of Kerkgoffsa (one of fundamental axioms of a science of safety) if safety of system depends exclusively on saving of its architecture in a secret, such system cannot be considered reliably protected.
8. Usage of resources of identification of the person which are easy for forging. Any systems providing transfer by fax of signatures, photocopies or scans of certificates/passports as a resource of identification of the person, are, as a matter of fact, decorative – lots of a tinsel and absence of real result (that is, in this case, safety). To forge such poor-quality copies made by means of means of the past (or even before last) generations, – easy as a pie. Actually, copies of signatures and passports can be for a well-tried remedy of identification of the person only when to copies are completely not similar. In other words, only the qualitative deliberate fake of the original can be considered as the good copy complicating an ill-intentioned fake.
9. The senseless invention of a bicycle. Very often developers new software in safety sphere try to create anew that has already been created to them, without having on that strong reasons. Many manufacturers of the software suffer “an originality syndrome” and as a result create the programs which do not have new useful functions. In itself it is yet terrible, but after all the new software frequently does not pass independent check, abounds with the errors already eliminated in other incarnations of similar programs, and in general, awfully all spoils. Before to start development new software, think, whether there are no already ready qualitative applications such and if your future program possesses really new and useful functions, whether to add these functions to something already existing instead of creating to itself and people an array of problems is better, trying existing to substitute this.
10. Ssubstitution of real safety by a false feeling of safety. An error so absurd, what even it is difficult to formulate its essence. Nevertheless, it so is extended what not to include it in this list simply it is impossible. People hand over keys from the system of safety to any who will be presented by the expert, and do it willingly, with enthusiasm and occasionally even without reflecting at all. “certification centers” speak, to whom to trust, depriving of users of possibility independently to make solutions on confidence; providers of services of e-mail offer server enciphering and decoding of the data, depriving of people of possibility independently to cipher letters and to control own cryptographic keys; operating systems autocratically start services and applications, depriving of users of possibility to be protected from transportable harmful soiftware. Do not trust handle of safety to the third parties! Certainly, not all can develop the reliable program or a policy in the field of safety is exclusively independent, but it does not mean yet that such program or a policy should deprive of you possibility to control it personally.

Thus, it is not necessary to rely on developers of this or that protocol, let even authors are the companies with a loud name.

1. Kopytin D. Safety in the inter-project collaboration []
2. Perrin Ch. Ten most widespread errors in sphere of computer safety which in no event cannot be made []

The author: Челябэнергопроект
Date: 03/23/2010

Remarks of experts of Челябэнергопроект:

смета проектных работ
©Chelenergyproject,, 2007-2013
DRA.RU - turnkey website; system administrator “Челябэнергопроект”
Main|About Us|Strategy of the company|
The competence / The competence|Contact Us