» 
allemand anglais arabe bulgare chinois coréen croate danois espagnol estonien finnois français grec hébreu hindi hongrois islandais indonésien italien japonais letton lituanien malgache néerlandais norvégien persan polonais portugais roumain russe serbe slovaque slovène suédois tchèque thai turc vietnamien
allemand anglais arabe bulgare chinois coréen croate danois espagnol estonien finnois français grec hébreu hindi hongrois islandais indonésien italien japonais letton lituanien malgache néerlandais norvégien persan polonais portugais roumain russe serbe slovaque slovène suédois tchèque thai turc vietnamien

définition - Cross-site_request_forgery

voir la définition de Wikipedia

   Publicité ▼

Wikipedia

Cross-site request forgery

                   

Cross-site request forgery, also known as a one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf[1]) or XSRF, is a type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts.[2] Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.

Contents

  Background

CSRF vulnerabilities have been known and in some cases exploited since 2001.[3] Because it is carried out from the user's IP address, some website logs might not have evidence of CSRF.[2] Exploits are under-reported, at least publicly, and as of 2007[4] there are few well-documented examples. About 18 million users of eBay's Internet Auction Co. at Auction.co.kr in Korea lost personal information in February 2008[5] . Customers of a bank in Mexico were attacked in early 2008 with an image tag in email. The link in the image tag changed the DNS entry for the bank in their ADSL router to point to a malicious website impersonating the bank.[6]

  Example and characteristics

  A National Vulnerability Database page describing a CSRF hole

The attack works by including a link or script in a page that accesses a site to which the user is known (or is supposed) to have been authenticated.[1] For example, one user, Bob, might be browsing a chat forum where another user, Fred, has posted a message. Suppose that Fred has crafted an HTML image element that references an action on Bob's bank's website (rather than an image file), e.g.,

<img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=Fred">

If Bob's bank keeps his authentication information in a cookie, and if the cookie hasn't expired, then the attempt by Bob's browser to load the image will submit the withdrawal form with his cookie, thus authorizing a transaction without Bob's approval.

A cross-site request forgery is a confused deputy attack against a Web browser. The deputy in the bank example is Bob's Web browser which is confused into misusing Bob's authority at Fred's direction.

The following characteristics are common to CSRF:

  • Involve sites that rely on a user's identity
  • Exploit the site's trust in that identity
  • Trick the user's browser into sending HTTP requests to a target site
  • Involve HTTP requests that have side effects

At risk are web applications that perform actions based on input from trusted and authenticated users without requiring the user to authorize the specific action. A user who is authenticated by a cookie saved in the user's web browser could unknowingly send an HTTP request to a site that trusts the user and thereby causes an unwanted action.

CSRF attacks using image tags are often made from Internet forums, where users are allowed to post images but not JavaScript.

CSRF attacks are often exploited in pair with XSS attacks, making CSRF vulnerabilities much more dangerous. Existence of an XSS vulnerability quite often allows to bypass the majority of existent anti-CSRF mechanisms. Such examples are described in details in "XSS & CSRF: Practical exploitation of post-authentication vulnerabilities in web applications" publication. [7]

  Limitations

Several things have to happen for cross-site request forgery to succeed:

  1. The attacker must target either a site that doesn't check the referrer header (which is common) or a victim with a browser or plugin bug that allows referrer spoofing (which is rare).
  2. The attacker must find a form submission at the target site, or a URL that has side effects, that does something (e.g., transfers money, or changes the victim's e-mail address or password).
  3. The attacker must determine the right values for all the form's or URL's inputs; if any of them are required to be secret authentication values or IDs that the attacker can't guess, the attack will fail.
  4. The attacker must lure the victim to a Web page with malicious code while the victim is logged in to the target site.

Note that the attack is blind; i.e., the attacker can't see what the target website sends back to the victim in response to the forged requests, unless he exploits a cross-site scripting or other bug at the target website. Similarly, the attacker can only target any links or submit any forms that come up after the initial forged request if those subsequent links or forms are similarly predictable. (Multiple targets can be simulated by including multiple images on a page, or by using JavaScript to introduce a delay between clicks.)

Given these constraints, an attacker might have difficulty finding logged-in victims or attackable form submissions. On the other hand, attack attempts are easy to mount and invisible to victims, and application designers are less familiar with and prepared for CSRF attacks than they are for, say, password-guessing dictionary attacks.

  Severity

According to the United States Department Of Homeland Security the most dangerous CSRF vulnerability ranks in at the 909th most dangerous software bug ever found, making this vulnerability more dangerous than most buffer overflows.[8] Other severity metrics have been issued for CSRF vulnerabilities that result in remote code execution with root privileges[9] as well as a vulnerability that can compromise a root certificate, which will completely undermine a public key infrastructure.[10]

  Forging login requests

An attacker may forge a request to log the victim in to a target website using the attacker's credentials; this is known as login CSRF. Login CSRF makes various novel attacks possible; for instance, an attacker can later log in to the site with his legitimate credentials and view private information like activity history that has been saved in the account.[11] The attack has been demonstrated against YouTube.[12]

  Other approaches to CSRF

Additionally, while typically described as a static type of attack, CSRF can also be dynamically constructed as part of a payload for a cross-site scripting attack, as demonstrated by the Samy worm, or constructed on the fly from session information leaked via offsite content and sent to a target as a malicious URL. CSRF tokens could also be sent to a client by an attacker due to session fixation or other vulnerabilities, or guessed via a brute-force attack,[13] rendered on a malicious page that generates thousands of failed requests. The attack class of "Dynamic CSRF", or using a per-client payload for session-specific forgery, was described[14] in 2009 by Nathan Hamiel and Shawn Moyer at the BlackHat Briefings,[15] though the taxonomy has yet to gain wider adoption.

A new vector for composing dynamic CSRF attacks was presented by Oren Ofer at a local OWASP chapter meeting on January 2012 - "AJAX Hammer - Dynamic CSRF".[citation needed]

  Prevention

Individual Web users using unmodified versions of the most popular browsers can do relatively little to prevent cross-site request forgery. Logging out of sites and avoiding their "remember me" features can mitigate CSRF risk; not displaying external images or not clicking links in spam or untrusted e-mails may also help.

Browser extensions such as RequestPolicy (for Mozilla Firefox) can prevent CSRF by providing a default-deny policy for cross-site requests. However, this can significantly interfere with the normal operation of many websites. The CsFire extension (also for Firefox) can mitigate the impact of CSRF with less impact on normal browsing, by removing authentication information from cross-site requests.

Web sites have various CSRF countermeasures available:

  • Requiring a secret, user-specific token in all form submissions and side-effect URLs prevents CSRF; the attacker's site cannot put the right token in its submissions[1]
  • Requiring the client to provide authentication data in the same HTTP Request used to perform any operation with security implications (money transfer, etc.)
  • Limiting the lifetime of session cookies
  • Checking the HTTP Referer header or(and) Checking the HTTP Origin header[16]
  • Ensuring that there is no clientaccesspolicy.xml file granting unintended access to Silverlight controls[17]
  • Ensuring that there is no crossdomain.xml file granting unintended access to Flash movies[18]
  • Verifying that the request's header contains a X-Requested-With. Used by Ruby on Rails (before v2.0) and Django (before v1.2.5). This protection has been proven unsecure[19] under a combination of browser plugins and redirects which can allow an attacker to provide custom HTTP headers on a request to any website, hence allow a forged request.

An easy and effective solution is to use a CSRF filter such as OWASP's CSRFGuard. The filter intercepts responses, detects if it is a html document and inserts a token in to the forms and optionally inserts script to insert tokens in ajax functions. The filter also intercepts requests to check that the token is present.

A variation on this approach is to double submit cookies for users who use JavaScript. If an authentication cookie is read using JavaScript before the post is made, JavaScript's stricter (and more correct) cross-domain rules will be applied. If the server requires requests to contain the value of the authentication cookie in the body of POST requests or the URL of dangerous GET requests, then the request must have come from a trusted domain, since other domains are unable to read cookies from the trusting domain.

Checking the HTTP Referer header to see if the request is coming from an authorized page is commonly used for embedded network devices because it does not increase memory requirements. However a request that omits the Referer header must be treated as unauthorized because an attacker can suppress the Referer header by issuing requests from FTP or HTTPS URLs. This strict Referer validation may cause issues with browsers or proxies that omit the Referer header for privacy reasons. Also, old versions of Flash (before 9.0.18) allow malicious Flash to generate GET or POST requests with arbitrary http request headers using CRLF Injection. Similar CRLF injection vulnerabilities in a client can be used to spoof the referrer of an http request.

To prevent forgery of login requests, sites can use these CSRF countermeasures in the login process, even before the user is logged in.

Sites with especially strict security needs, like banks, often log users off after (for example) 15 minutes of inactivity.

Using the HTTP specified usage for GET and POST, in which GET requests never have a permanent effect, is good practice but is not sufficient to prevent CSRF. Attackers can write JavaScript or ActionScript that invisibly submits a POST form to the target domain. However, filtering out unexpected GETs prevents some particular attacks, such as cross-site attacks using malicious image URLs or link addresses and cross-site information leakage through <script> elements (JavaScript hijacking); it also prevents (non-security-related) problems with aggressive web crawlers and link prefetching.[1]

Cross-site scripting (XSS) vulnerabilities (even in other applications running on the same domain) allow attackers to bypass CSRF preventions.[20]

  See also

  References

  1. ^ a b c d Shiflett, Chris (December 13, 2004). "Security Corner: Cross-Site Request Forgeries". php|architect (via shiflett.org). http://shiflett.org/articles/cross-site-request-forgeries. Retrieved 2008-07-03. 
  2. ^ a b Ristic, Ivan (2005). Apache Security. O'Reilly Media. p. 280. ISBN 0-596-00724-8. 
  3. ^ Burns, Jesse (2005). "Cross Site Request Forgery: An Introduction To A Common Web Weakness". Information Security Partners, LLC. http://www.isecpartners.com/files/CSRF_Paper.pdf. Retrieved 2011-12-12. 
  4. ^ Christey, Steve and Martin, Robert A. (May 22, 2007). "Vulnerability Type Distributions in CVE (version 1.1)". MITRE Corporation. http://cwe.mitre.org/documents/vuln-trends/index.html. Retrieved 2008-06-07. 
  5. ^ "Hacker Steals Data on 18M Auction Customers in South Korea". DarkReader. February 2008. http://www.darkreading.com/security/perimeter-security/211201111/. Retrieved 13 April 2012. 
  6. ^ "List of incidents for which Attack Method is Cross Site Request Forgery (CSRF)". Web Application Security Consortium. February 2008. http://www.webappsec.org/projects/whid/byclass_class_attack_method_value_cross_site_request_forgery_(csrf).shtml. Retrieved 2008-07-04. 
  7. ^ Nizamutdinov, Marsel (January 17, 2012). "XSS & CSRF: Practical exploitation of post-authentication vulnerabilities in web applications". https://www.htbridge.com/publications/xss_csrf_practical_exploitation_of_post_authentication_vulnerabilities_in_web_applications.html. 
  8. ^ US-CERT vulnerability list by severity metric
  9. ^ cPanel Remote Root
  10. ^ OpenCA CSRF
  11. ^ Adam Barth, Collin Jackson, and John C. Mitchell, Robust Defenses for Cross-Site Request Forgery, Proceedings of the 15th ACM Conference on Computer and Communications Security, ACM 2007
  12. ^ Jeremiah Grossman, Google YouTube crossdomain security flaw
  13. ^ Inferno Security Blog Brute-forcing CSRF tokens
  14. ^ Weaponizing Web 2.0
  15. ^ Dynamic CSRF
  16. ^ http://people.mozilla.org/~bsterne/content-security-policy/origin-header-proposal.html
  17. ^ Client access policy file to allow cross-domain access by Silverlight controls
  18. ^ Cross-domain policy file usage recommendations for Flash Player
  19. ^ "Django 1.2.5 release notes". Django. http://docs.djangoproject.com/en/1.2/releases/1.2.5/#csrf-exception-for-ajax-requests. 
  20. ^ "Article about CSRF and same-origin XSS"

  External links

   
               

 

Toutes les traductions de Cross-site_request_forgery


Contenu de sensagent

  • définitions
  • synonymes
  • antonymes
  • encyclopédie

  • definition
  • synonym

Dictionnaire et traducteur pour mobile

⇨ Nouveau : sensagent est maintenant disponible sur votre mobile

   Publicité ▼

sensagent's office

Raccourcis et gadgets. Gratuit.

* Raccourci Windows : sensagent.

* Widget Vista : sensagent.

dictionnaire et traducteur pour sites web

Alexandria

Une fenêtre (pop-into) d'information (contenu principal de Sensagent) est invoquée un double-clic sur n'importe quel mot de votre page web. LA fenêtre fournit des explications et des traductions contextuelles, c'est-à-dire sans obliger votre visiteur à quitter votre page web !

Essayer ici, télécharger le code;

SensagentBox

Avec la boîte de recherches Sensagent, les visiteurs de votre site peuvent également accéder à une information de référence pertinente parmi plus de 5 millions de pages web indexées sur Sensagent.com. Vous pouvez Choisir la taille qui convient le mieux à votre site et adapter la charte graphique.

Solution commerce électronique

Augmenter le contenu de votre site

Ajouter de nouveaux contenus Add à votre site depuis Sensagent par XML.

Parcourir les produits et les annonces

Obtenir des informations en XML pour filtrer le meilleur contenu.

Indexer des images et définir des méta-données

Fixer la signification de chaque méta-donnée (multilingue).


Renseignements suite à un email de description de votre projet.

Jeux de lettres

Les jeux de lettre français sont :
○   Anagrammes
○   jokers, mots-croisés
○   Lettris
○   Boggle.

Lettris

Lettris est un jeu de lettres gravitationnelles proche de Tetris. Chaque lettre qui apparaît descend ; il faut placer les lettres de telle manière que des mots se forment (gauche, droit, haut et bas) et que de la place soit libérée.

boggle

Il s'agit en 3 minutes de trouver le plus grand nombre de mots possibles de trois lettres et plus dans une grille de 16 lettres. Il est aussi possible de jouer avec la grille de 25 cases. Les lettres doivent être adjacentes et les mots les plus longs sont les meilleurs. Participer au concours et enregistrer votre nom dans la liste de meilleurs joueurs ! Jouer

Dictionnaire de la langue française
Principales Références

La plupart des définitions du français sont proposées par SenseGates et comportent un approfondissement avec Littré et plusieurs auteurs techniques spécialisés.
Le dictionnaire des synonymes est surtout dérivé du dictionnaire intégral (TID).
L'encyclopédie française bénéficie de la licence Wikipedia (GNU).

Copyright

Les jeux de lettres anagramme, mot-croisé, joker, Lettris et Boggle sont proposés par Memodata.
Le service web Alexandria est motorisé par Memodata pour faciliter les recherches sur Ebay.
La SensagentBox est offerte par sensAgent.

Traduction

Changer la langue cible pour obtenir des traductions.
Astuce: parcourir les champs sémantiques du dictionnaire analogique en plusieurs langues pour mieux apprendre avec sensagent.

Dernières recherches dans le dictionnaire :

5851 visiteurs en ligne

calculé en 0,046s

   Publicité ▼

Je voudrais signaler :
section :
une faute d'orthographe ou de grammaire
un contenu abusif (raciste, pornographique, diffamatoire)
une violation de copyright
une erreur
un manque
autre
merci de préciser :

Mon compte

connexion

inscription

   Publicité ▼