Sécuriser une application client/server.

Bonjour à tous.

Je suis en train de développer une application client/server basée sur les sockets (TCP) et sur un protocole maison (le tout en C/C++).

 l'heure actuelle, mon serveur est écrit (ou presque), et se pose maintenant la question de la sécurité.

Je compte garder les sessions ouvertes tout le temps ou l'application côté client est ouverte, cela dit il me faudra bien à un moment ou un autre faire un système de compte (avec username, password) pour accepter ou non les connexions des clients.

Donc, il va falloir à un moment crypter les données pour ne pas qu'elles soient lisibles par un tier qui sniffe le réseau. Quelles sont les solutions qui existent? Est-il possible d'avoir une solution qui n'implique pas de changement dans le code du serveur, ni du côté client (SSL?)?
Est-ce que je dois plutôt regarder du côté de la cryptographie?

De plus j'aimerai savoir quels sont les risques pour un tel serveur? A partir du moment ou je maitrise la connection TCP du côté serveur, quelles sont les possibilités pour les éventuels hackeur de venir trifouiller sur le serveur?

Les seules attaques que je vois qui pourrait poser problème sont un client qui demande 100000 connections en même temps pour faire tomber mon serveur, ou éventuellement une requête sous une fausse IP, mais dans ce cas là, la réponse ne repartirait pas au "pirate" mais bien a celui dont l'identité a été usurpé.

C'est un monde que je ne connais pas encore très bien, mais je suis extrémement motivé pour apprendre. Je n'ai pas trouvé beaucoup de resources sur google, si vous avez des liens, des explications voire des logiciel open source dont je peux m'inspirer à me proposer, je suis preneur.

Merci d'avance.

Je pense avoir trouver un truc intéressant:

http://www.google.fr/url?sa=t&rct=j&...LkADwg&cad=rja

Cela-dit, je reste demandeur pour tous les types d'attaques que je risque. Voire d'autre liens ou commentaires si vous avez!

Merci.

Citation:

---

Envoyé par wadabush

Les seules attaques que je vois qui pourrait poser problème sont un client qui demande 100000 connections en même temps pour faire tomber mon serveur, ou éventuellement une requête sous une fausse IP, mais dans ce cas là, la réponse ne repartirait pas au "pirate" mais bien a celui dont l'identité a été usurpé.

---

Ce dont tu parles, c'est du DoS (Deny of Service) ou du spoofing IP (usurpation) et malheureusement il y a d'autres types d'attaque.

Le buffer overflow (à mon avis, le plus critique dans ton cas), c'est quand le client envoie plus de données que le serveur n'est prêt a en accepter ou alors des données trafiquées qui font prendre des vessies pour des lanternes à ton programme. Un buffer overflow bien exploité permet de prendre la main à distance (lancer un shell) en utilisant l'identité de ton serveur (en général, un service ou un daemon ont beaucoup de privilèges).

Le cross scripting, c'est à dire envoyer des données "spéciales" à ton serveur qui seront affichées par un autre client et qui lui pourriront la vie (les logiciels de chat ou bien encore les forums sont sensibles à ce genre d'attaque). Je ne sais pas si ton programme peut être une cible à ce genre d'attaque.

Le SQL injection, consiste à envoyer des données particulière à ton serveur et ces données seront utilisées pour détourner les requêtes SQL faites par ton serveur. Les programme sensibles à ce genre d'attaque sont tous ceux qui sont liés à une base de données.

En règle général, une bonne programmation défensive ne fait jamais jamais confiance aux données envoyées par le client. Ces données sont vérifiées, contrôlées et analysées et enfin traitées.

La cryptographie ne sert en aucun cas à se prémunir de ces attaques. Le rôle de la crypto, c'est uniquement de sécuriser le canal de communication (identification, authentification, non rejeu de la session).

Pour ce qui est de la crypto, tu peux utiliser openssl en surcouche sur tes socket TCP. L'avantage est qu'alors tu peux passer en crypto NULL en phase de développement (sans crypto donc) ce qui est bien pratique pour debuguer.

Merci de cette réponse.

Je me doutais bien que le sujet était vaste... Maintenant, dans tout ce que tu m'as décris, si je mets en place mon propre protocole qui correspondra en gros a :

Taille_du_message
ID de l'API
Parametre 1
Parametre 2
Parametre 3
...

Même si j'ai une base de donnée SQL derrière si je ne reconnais pas le message, qu'il est trop long a mon gout je suis toujours a temps de l'ignorer et fermer la socket. Alors je dis pas qu'il n'aura pas de failles, mais disons que je reste maitre de ce que mon serveur peut faire.

D’où mes seules craintes sont liées a l'espionnage de données par un tier... Et tu as répondu a ma question.