Skip to content
KitploitKITPLOIT
OutilsBlog
Soumettre
OutilsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

··Flux·Contact·Confidentialité·© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
name_reverser — Application Rails bidon pour démontrer la vulnérabilité CVE-2013-0156 | Kitploit
Outils/GitHubGitHub/terracatta/name_reverser
Analyse des VulnérabilitésExploitationExploitation d'Applications WebTests d'IntrusionApprentissage et Éducation
GitHubterracatta/name_reverser

name_reverser

Application Rails bidon pour démontrer la vulnérabilité CVE-2013-0156

Voir le dépôt
il y a 13 ansPas encore vérifié

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Partager

== Bienvenue dans Rails

Rails est un framework d'applications web qui inclut tout le nécessaire pour créer des applications web adossées à une base de données selon le modèle Model-View-Control.

Ce modèle sépare la vue (également appelée présentation) en modèles « passifs » qui sont principalement chargés d'insérer des données pré-construites entre les balises HTML. Le modèle contient les objets métier « intelligents » (tels que Account, Product, Person, Post) qui détiennent toute la logique métier et savent comment se persister dans une base de données. Le contrôleur gère les requêtes entrantes (telles que Save New Account, Update Product, Show Post) en manipulant le modèle et en dirigeant les données vers la vue.

Dans Rails, le modèle est géré par une couche de mapping objet-relationnel appelée Active Record. Cette couche vous permet de présenter les données des lignes d'une base de données comme des objets et d'enrichir ces objets de données avec des méthodes de logique métier. Vous pouvez en apprendre davantage sur Active Record dans link:files/vendor/rails/activerecord/README.html.

Le contrôleur et la vue sont gérés par Action Pack, qui gère les deux couches via ses deux parties : Action View et Action Controller. Ces deux couches sont regroupées dans un même paquetage en raison de leur forte interdépendance, contrairement à la relation entre Active Record et Action Pack qui est beaucoup plus distincte. Chacun de ces paquetages peut être utilisé indépendamment en dehors de Rails. Vous pouvez en savoir plus sur Action Pack dans link:files/vendor/rails/actionpack/README.html.

== Pour commencer

  1. À l'invite de commande, créez une nouvelle application Rails : rails new myapp (où myapp est le nom de l'application)

  2. Déplacez-vous dans le répertoire myapp et démarrez le serveur web : cd myapp; rails server (exécutez avec --help pour les options)

  3. Rendez-vous sur http://localhost:3000/ et vous verrez : « Welcome aboard: You're riding Ruby on Rails! »

  4. Suivez les directives pour commencer à développer votre application. Vous trouverez les ressources suivantes utiles :

  • Le guide de démarrage : http://guides.rubyonrails.org/getting_started.html
  • Le livre de tutoriel Ruby on Rails : http://www.railstutorial.org/

== Déboguer Rails

Parfois, votre application rencontre un problème. Heureusement, il existe de nombreux outils pour vous aider à la déboguer et à la remettre sur les rails.

Le premier endroit à vérifier est le fichier journal de l'application. Lancez des commandes « tail -f » sur server.log et development.log. Rails affichera automatiquement les informations de débogage et d'exécution dans ces fichiers. Les informations de débogage seront également affichées dans le navigateur pour les requêtes provenant de 127.0.0.1.

Vous pouvez également consigner vos propres messages directement dans le fichier journal à partir de votre code en utilisant la classe de journalisation Ruby depuis vos contrôleurs. Exemple :

class WeblogController < ActionController::Base def destroy @weblog = Weblog.find(params[:id]) @weblog.destroy logger.info("#{Time.now} Destroyed Weblog ID ##{@weblog.id}!") end end

Le résultat sera un message dans votre fichier journal ressemblant à ceci :

Mon Oct 08 14:22:29 +1000 2007 Destroyed Weblog ID #1!

Plus d'informations sur l'utilisation du journal sont disponibles sur http://www.ruby-doc.org/core/

La documentation Ruby est également disponible sur http://www.ruby-lang.org/. Plusieurs livres sont aussi disponibles en ligne :

  • Programming Ruby : http://www.ruby-doc.org/docs/ProgrammingRuby/ (Pickaxe)
  • Learn to Program : http://pine.fm/LearnToProgram/ (un guide pour débutants)

Ces deux livres vous mettront à niveau sur le langage Ruby ainsi que sur la programmation en général.

== Débogueur

La prise en charge du débogueur est disponible via la commande debugger lorsque vous démarrez votre serveur Mongrel ou WEBrick avec --debugger. Cela signifie que vous pouvez interrompre l'exécution à tout moment dans le code, examiner et modifier le modèle, puis reprendre l'exécution ! Vous devez installer ruby-debug pour exécuter le serveur en mode débogage. Avec les gems, utilisez sudo gem install ruby-debug. Exemple :

class WeblogController < ActionController::Base def index @posts = Post.all debugger end end

Ainsi, le contrôleur acceptera l'action, exécutera la première ligne, puis vous présentera une invite IRB dans la fenêtre du serveur. Vous pourrez alors faire des choses telles que :

@posts.inspect => "[#<Post:0x14a6be8 @attributes={"title"=>nil, "body"=>nil, "id"=>"1"}>, #<Post:0x14a6620 @attributes={"title"=>"Rails", "body"=>"Only ten..", "id"=>"2"}>]" @posts.first.title = "hello from a debugger" => "hello from a debugger"

...et mieux encore, vous pouvez examiner comment vos objets d'exécution fonctionnent réellement :

f = @posts.first => #<Post:0x13630c4 @attributes={"title"=>nil, "body"=>nil, "id"=>"1"}> f. Display all 152 possibilities? (y or n)

Enfin, lorsque vous êtes prêt à reprendre l'exécution, vous pouvez saisir « cont ».

== Console

La console est un shell Ruby qui vous permet d'interagir avec le modèle de domaine de votre application. Vous y trouverez toutes les parties de l'application configurées, exactement comme lorsque l'application est en cours d'exécution. Vous pouvez inspecter les modèles de domaine, modifier des valeurs et enregistrer dans la base de données. Le lancement du script sans argument le démarre dans l'environnement de développement.

Pour démarrer la console, exécutez rails console depuis le répertoire de l'application.

Options :

  • Passer l'argument -s, --sandbox annulera toute modification apportée à la base de données.
  • Passer un nom d'environnement comme argument chargera l'environnement correspondant. Exemple : rails console production.

Pour recharger vos contrôleurs et modèles après le lancement de la console, exécutez reload!

Plus d'informations sur irb sont disponibles à l'adresse : link:http://www.rubycentral.org/pickaxe/irb.html

== dbconsole

Vous pouvez accéder directement à la ligne de commande de votre base de données via rails dbconsole. Vous serez connecté à la base de données avec les identifiants définis dans database.yml. Le lancement du script sans argument vous connectera à la base de développement. Le passage d'un argument vous connectera à une autre base, par exemple rails dbconsole production. Fonctionne actuellement pour MySQL, PostgreSQL et SQLite 3.

== Description du contenu

La structure de répertoires par défaut d'une application Ruby on Rails générée :

|-- app | |-- assets | |-- images | |-- javascripts | -- stylesheets | |-- controllers | |-- helpers | |-- mailers | |-- models | -- views | -- layouts |-- config | |-- environments | |-- initializers | -- locales |-- db |-- doc |-- lib | -- tasks |-- log |-- public |-- script |-- test | |-- fixtures | |-- functional | |-- integration | |-- performance | -- unit |-- tmp | |-- cache | |-- pids | |-- sessions | -- sockets -- vendor |-- assets -- stylesheets -- plugins

app Contient tout le code spécifique à cette application particulière.

app/assets Contient des sous-répertoires pour les images, les feuilles de style et les fichiers JavaScript.

app/controllers Contient des contrôleurs qui devraient être nommés comme weblogs_controller.rb pour un mappage d'URL automatisé. Tous les contrôleurs doivent descendre de ApplicationController, qui descend lui-même de ActionController::Base.

app/models Contient des modèles qui devraient être nommés comme post.rb. Par défaut, les modèles descendent de ActiveRecord::Base.

app/views Contient les fichiers de modèles pour la vue, qui devraient être nommés comme weblogs/index.html.erb pour l'action WeblogsController#index. Toutes les vues utilisent la syntaxe eRuby par défaut.

app/views/layouts Contient les fichiers de modèles pour les layouts à utiliser avec les vues. Cela modélise la méthode courante d'en-tête/pied de page pour encapsuler les vues. Dans vos vues, définissez un layout à l'aide de layout :default et créez un fichier nommé default.html.erb. Dans default.html.erb, appelez <% yield %> pour rendre la vue en utilisant ce layout.

app/helpers Contient des helpers de vue qui devraient être nommés comme weblogs_helper.rb. Ceux-ci sont générés automatiquement lorsque vous utilisez les générateurs de contrôleurs. Les helpers peuvent être utilisés pour encapsuler des fonctionnalités pour vos vues dans des méthodes.

config Fichiers de configuration pour l'environnement Rails, la carte de routage, la base de données et autres dépendances.

db Contient le schéma de base de données dans schema.rb. db/migrate contient toute la séquence de migrations pour votre schéma.

doc Ce répertoire stockera la documentation de votre application lorsqu'elle sera générée à l'aide de rake doc:app

lib Bibliothèques spécifiques à l'application. En gros, tout code personnalisé qui n'appartient pas aux contrôleurs, aux modèles ou aux helpers. Ce répertoire est dans le chemin de chargement.

public Le répertoire accessible au serveur web. Contient également les répartiteurs et les fichiers HTML par défaut. Il doit être défini comme DOCUMENT_ROOT de votre serveur web.

script Scripts d'aide pour l'automatisation et la génération.

test Tests unitaires et fonctionnels accompagnés de fixtures. Lorsque vous utilisez la commande rails generate, des fichiers de test modèles sont générés pour vous et placés dans ce répertoire.

vendor Bibliothèques externes dont l'application dépend. Inclut également le sous-répertoire plugins. Si l'application a des rails figés (frozen rails), ces gems vont aussi ici, sous vendor/rails/. Ce répertoire est dans le chemin de chargement.

Télécharger l’outil