Thursday, September 19, 2013

Passive Vulnerability Scanner ( PVS ) 4.0 - Nessus

Tenable Nessus -  Passive Vulnerability Scanner

                     provides visibility into both server and client-side vulnerabilities, discovers the use of common protocols and services (e.g., HTTP, SQL, file sharing), and performs full asset discovery for both IPv4 and IPv6, and even on hybrid networks.

                    Unique, real-time vulnerability scanner continuously uncovers hidden vulnerabilities
and provides full asset discovery of BYOD and virtual systems.

Nessus Passive Vulnerability Scanner (PVS) is perfect to drop into any network or network segment for continuous vulnerability detect and full asset discovery. Try it free to monitor vulnerabilities up to 16 IP addresses.

System Requirements

  • CPU: 1 x dual-core 2 GHz CPU (32 or 64 bit)
  • Memory: 2 GB RAM (4 GB RAM recommended)
  • OS: Windows, Red Hat ES 5, Red Hat ES 6

Passive Vulnerability Scanner Features

BYOD and Shadow IT Detection:
                                      The Tenable Passive Vulnerability Scanne (PV) continuously and passively detects mobile devices, virtual infrastructure, and cloud applications (often described as "shadow IT") used on your network. Whether these assets are managed or unmanaged, PVS is the only scanner that can detect them, their vulnerabilities, and behavior that create compliance risk and security exposure. PVS detects operating systems, services, and applications, as well as vulnerabilities in all network traffic.


Self-contained User Interface:
                                           PVS easily installs in networks to monitor network traffic at the packet level. The integrated web-based interface provides user management, scanner configuration, plugin updates, report set-up, and customization. This self-contained solution makes it easy to discover common protocols and services (e.g., HTTP, SQL, file sharing), eliminating gaps in time and covering areas of your network and assets that active scanners alone cannot. With its integrated interface, PVS provides unparalleled point monitoring for highly-sensitive networks or network segments.


Download Link : http://www.tenable.com/products/passive-vulnerability-scanner/download

Thanks,

RRN Technologies Team.




Wednesday, September 4, 2013

SAP ERP Penetration Testing framework / Tools List

SAP ERP Penetration Testing framework / Tools List :

  • Bizploit By Onapsis
  • Sapyto By Cyber System Security
  • ERPScan’s By SAP AG

                     
Bizploit :
            is the first Opensource SAP ERP Penetration Testing framework. Developed by the Onapsis Research Labs, Bizploit assists security professionals in the discovery, exploration, vulnerability assessment and exploitation phases of specialized ERP Penetration Tests.


Currently, Bizploit is shipped with many plugins to assess the security of SAP business platforms. Plugins for other popular ERPs will be included in the short term.



  • Download Bizploit v1.50-rc1 for Windows  
  • Download Bizploit v1.50-rc1 for Linux

  • Sapyto:
               is the first SAP Penetration Testing Framework. Fully developed at CYBSEC-Labs, sapyto provides support to information security professionals in SAP platform discovery, investigation and exploitation activities.

              Sapyto is periodically updated with the outcome of the deep research constantly carried out by CYBSEC-Labs on the various security aspects in SAP systems.

              Although sapyto is a versatile and powerful tool, it is of major importance for it to be used by consultants who are highly skilled and specialized in its usage, preventing any interference with your organization’s usual SAP operation.

               To obtain further information about specific SAP security services, please visit our SAP Security section.

    The following versions of sapyto are available at this moment:


    Sapyto Public Edition (v0.99) for Windows [DOWNLOAD]
    Sapyto Public Edition (v0.99) for Linux [DOWNLOAD]

    ERPScan's:
                     SAP Pentesting Tool is NOT a demo or part of professional product called ERPScan Security Scanner it is just a number of perl scripts for penetration testers.
    Overview
    ERPScan's SAP Pentesting Tool is a freeware tool that is intended for penetration testers and security officers for vulnerability assessment of SAP systems using Black Box testing methodologies. It means that you do not need to know any information about the target system or have a legal account in it. All the information will be collected by SAP Pentesting tool.


    Updated release 0.6 from 01.10.2012

    - Total 31 modules
    - 18 Information gathering
    - 3 Command execution
    - 8 Aux
    - 4 DoS
    - Exploit for Verb Tampering (add user and add role)
    - P4 password decryptor plugin
    - ~40 default public ICM pages scan

    Features
    Using ERPScan's SAP Pentesting Tool you can:
    • Obtain information using information disclosure vulnerability;
    • Exploit potential vulnerabilities;
    • Collect business critical data or the data for conducting other attacks
    If you want to test professional product please fill this form.

    Monday, September 2, 2013

    SpiderFoot : Multi-platform open-source footprinting and intelligence gathering tool.


    SpiderFoot:
                       is an open source footprinting tool, available for Windows and Linux. It is written in Python and provides an easy-to-use GUI. SpiderFoot obtains a wide range of information about a target, such as web servers, netblocks, e-mail addresses and more.

                       SpiderFoot is now entirely written in Python, with packages provided for running on Linux/BSD/Solaris systems as well as a py2exe package that can be run on Windows. Once started, SpiderFoot starts up an internal web server that you must then visit using a web browser (IE, FireFox and Chrome should be fine.

                       All data is stored locally in a SQLite database. This enables a lot of flexibility in data analysis, querying and reporting that I expect to become more fully available in future releases.






        - Collects SSL certificate information and performs a number of checks.
        - Identifies social media presence on LinkedIn, Twitter, Facebook, etc.
        - Identifies the use of Javascript frameworks like jQuery, etc.
        - Identifies the use of externally hosted Javascript.
        - Looks across all Internet TLDs for presence of the target.
        - Performs faster port scanning, with the addition of banner grabbing.
        - Performs more thorough DNS analysis of the target.
        - Includes many bug fixes and internal improvements.

     Download Link : http://sourceforge.net/projects/spiderfoot/files/

    More Info : https://github.com/smicallef/spiderfoot/wiki

    Grab it from: http://www.spiderfoot.net/







    Wednesday, August 28, 2013

    Nginx Anti Xss & Sql Injection : NAXSI ( Open-Source WAF )


    NAXSI ( Nginx Anti Xss & Sql Injection ) :
                                                                 is an open source WAF ( Web Application Firewall ) , high performance, low rules maintenance, Web Application Firewall module for Nginx. 



      _   _                _ 
     | \ | | __ ___  _____(_)
     |  \| |/ _` \ \/ / __| |
     | |\  | (_| |>  <\__ \ |
     |_| \_|\__,_/_/\_\___/_|
     
                              goal is to help people to secure their web application against attacks 
    such as SQL Injection, Cross Site Scripting, Cross Site Request Forgery, 
    Local & Remote file inclusions and such. 
    The difference with most WAF (Web Applicative Firewalls) out there is that 
    it does not rely on signatures to detect attacks. It is using a simpler model, 
    where instead of trying to detect "known" attacks, it will detect unexpected 
    characters in the HTTP request/arguments. Each kind of unusual character will 
    increase the score of the request. If the request reaches a score that's 
    considered "too high", the request will be denied, and the user will be 
    redirected to a "forbidden" page. Yes, it works a bit like a spam system. 
    
    
    
    

    NAXSI Project:
                            The NAXSI Project is not so known like the ModSecurity open source project, but has a very interesting approach and features.
    NAXSI uses the small and performant reverse proxy engine of Nginx web server instead of the full blown Apache engine used by ModSecurity (and from a security point of view: the lesser code).
    Following are the major feature of NAXSI:
    • Protects from XSS, SQL injections, CSRF, file inclusion
    • Fast engine
    • Relative simple configuration
    • Check GET/POST requests
    • Check HTTP headers and cookies
    • Forbid dangerous symbols and SQL keywords
    • Allows whitelist approach configuration creating a web application baseline
    • Able to run in learn or production mode
    • Uses no signature of known attack

    Installation

    Let’s do a quick installation with ubuntu sever 12.04 LTS. You may also install it from the sources following the Nginx prerequisites for reference. After you’ve installed the basic server with openssh, install NAXSI with:
     sudo apt-get install nginx-naxsi

    Initial configuration

    In the nginx configuration file (/etc/nginx/nginx.conf) uncomment this line to activate the basic rulesets:
    ##
    # nginx-naxsi config
    ##
    # Uncomment it if you installed nginx-naxsi
    ##
    include /etc/nginx/naxsi_core.rules;
    
    Note that this file is not an attack signature repository but rather a “score rules” set. Let’s configure NAXSI for our website www.scip.ch. To do so edit the Nginx configuration file in /etc/nginx/sites-enabled/default and add following entries in the server context:

    server {
            proxy_set_header Proxy-Connection “”;    
            listen   80;
    
            location / {
                    # put your website IP here
                    proxy_pass http://80.74.141.2/;
    
                    # put your website FQDN here
                    proxy_set_header Host www.scip.ch;
    
                    # Uncomment to enable naxsi on this location
                    include /etc/nginx/naxsi.rules;
                    }
    
            # Only for nginx-naxsi : process denied requests
            location /RequestDenied {
                    # For example, return an HTTP error code
                    return 418;
                    }
            }
     
    Now you should be able to start the nginx service that will bring up the NASXI with following command:

    sudo service nginx start
     
    Be sure to check for error messages on the console or in the error log found in /var/log/nginx/error.log and verify with sudo netstat -antup that nginx daemon is opening the configured port (tcp/80 in our case). The output should look like this:

    Active Internet connections (servers and established)
     
    Proto Recv-Q Send-Q Local Address    Foreign Address   State       PID/Program name
    tcp        0      0 0.0.0.0:80       0.0.0.0:*         LISTEN      9865/nginx
    tcp        0      0 0.0.0.0:22       0.0.0.0:*         LISTEN      8484/sshd
    tcp        0      0 127.0.0.1:6010   0.0.0.0:*         LISTEN      9627/0
    tcp        0      0 127.0.0.1:6011   0.0.0.0:*         LISTEN      9062/1
    tcp        0     32 x.y.z.52:22      x.y.z.36:49749    ESTABLISHED 9046/sshd: anco
    udp        0      0 0.0.0.0:68       0.0.0.0:*                     649/dhclient3
    

    To test if it works, start a browser session and point it to the ip address of your test server (x.y.z.52:80) and you should see the website you configured (www.scip.ch) in the config file above. To continue further testing make sure you will proxying all web request to the nginx-NAXSI WAF. To accomplish this you can ether use the web-proxy configuration setting in the browser or fake the testing website ip address in your system hostfile. I prefer to put the ip address in my hostfile:

    x.y.z.52     www.scip.ch
     
    Here are the location of the target hosts file (you need admin right to save changes):

    OS Host Configuration File
    Windows %SYSTEMROOT%\system32\drivers\etc\hosts
    Linux /etc/hosts
     
    Now we can browse to www.scip.ch and be sure that our test NAXSI WAF will inspect the content and remember that by now the configuration is in learning mode; it will only report errors in the nginx error logs (/var/log/nginx/error.log) and not block any bad scored request.

    How It Works

    The naxsi_core.rules are responsible for scoring the HTTP input and looks like this (excerpt):
    MainRule "str:;" "msg:; in stuff" "mz:BODY|URL|ARGS" "s:$SQL:4" id:1008;
    #
    MainRule "str:<" "msg:html open tag" "mz:ARGS|URL|BODY|$HEADERS_VAR:Cookie"
    "s:$XSS:8" id:1302;
    #
    MainRule "str:&#" "msg: utf7/8 encoding" "mz:ARGS|BODY|URL|$HEADERS_VAR:Cookie"
    "s:$EVADE:4" id:1400;
    #
    MainRule "rx:.ph*|.asp*" "msg:asp/php file upload!" "mz:FILE_EXT"
    "s:$UPLOAD:8" id:1500;
    
    Insight this file is the logic configuration used to score the input; the result will be used in /etc/nginx/naxsi.rules to decide if such input may be allowed or not. The format is quite simple:
    1. Define what to look for: string (str:) or regular expression (rx:)
    2. Define message to report into logfiles (msg:)
    3. Put the rule a category (s:)
    4. Assign rule identifier (id:)
    5. Define where to look for (mz:) and short description below
    mz entry Look in
    URL URL path
    ARGS HTTP argument
    BODY HTML body entry
    $HEADERS_VAR: HTTP header variable
    Now let’s take a look on the second NAXSI config file /etc/nginx/naxsi.rules where the main NAXSI behavior is defined; this is how it looks like:

    # config mode section
    LearningMode;
    SecRulesEnabled;
    #SecRulesDisabled;
    DeniedUrl "/RequestDenied";
    #
    # check rules section
    CheckRule "$SQL >= 8" BLOCK;
    CheckRule "$RFI >= 8" BLOCK;
    CheckRule "$TRAVERSAL >= 4" BLOCK;
    CheckRule "$EVADE >= 4" BLOCK;
    CheckRule "$XSS >= 8" BLOCK;
     
    Here is an explanation of the contents:
    1. LearningMode – activates learning mode; in this mode requests aren’t blocked and white lists may be created.
    2. SecRulesEnabled or SecRulesDisabled – to activate or disable NAXSI for this location/section.
    3. DeniedURL – redirect URL for blocked requests; can be an HTTP error code (like 4xx or 5xx) or forward to an HTML site with code to help track false-positives.
    4. CheckRule – per-category check scores; the score we saw above will be evaluated here. If a request hits a score in the naxsi.core.rules, this score will be recorded and added to each category (SQL, XSS, EVADE, ...) if the overall score for any of the categories is reached (8 in SQL per default) the input is treated as bad.
    When you use the whitelist (positive secure model) approach you’ll find also the white-list entries (BasicRule statement) in this config file:
    # Whitelist '|', as it's used on the /report/ page, in argument 'd'
    BasicRule wl:1005 "mz:$URL:/report/|$ARGS_VAR:d";
    # Whitelist ',' on URL zone as it's massively used for URL rewritting !
    BasicRule wl:1008 "mz:URL";
    
    The entry above will result in disabling some part of the check rule in naxsi_core.rules allowing a specific behavior and eliminate false-positives. BasicRule could be more or less specific at your pace (and security needs).

    Information Gathering

    At this stage we have our test installation inspecting the HTTP flow and reporting bad things in the /var/log/nginx/error.log file, let’s take a look on how NAXSI error entry looks like:

    > error.log <
    2012/11/30 04:57:55 [error] 9866#0: *47 NAXSI_FMT: ip=x.y.z.36&
    server=x.y.z.52&uri=/testmiztot&total_processed=8589934625&
    total_blocked=679029381853280060&zone0=URL&id0=1999&
    var_name0=, client:x.y.z.36, server: localhost, 
    request: "GET /testmiztot HTTP/1.1", host: "x.y.z.52"
    

    As you can see it’s a special error message: it was generated on a “special” HTTP URL GET request and is not a really bad request. To test the functionality on the WAF I’ve created this test-rule in the  

    /etc/nginx/naxsi_core.rules:
    MainRule "str:testmiztot" "msg:foobar test pattern" "mz:URL" "s:$SQL:42" id:1999;

    This rule will trigger whenever the testmiztot string is detected in the address part (mz:URL) of the HTTP GET request and score as 42 (s:$SQL:42) in the SQL category. This will be evaluated as bad because the SQL category limit is 8. The msg: text will be shown in the learning mode log used to generate the white-list baseline.

     Analyze in detail the meaning of these commands:
    • LearningMode - Training Mode is enabled. Requests are not blocked, White-shaped leaf.
    • SecRulesEnabled - NAXSI enabled for this location. If you want to switch off for another location (for example, a protected inner zone), then do it SecRulesDisabled.
    • DeniedURL - URL redirect for the denied requests.
    • CheckRule - checking the "penalty points" query by category.
    • / Etc / nginx / mynaxsi.rules - generated rules (not yet gener - commented out).

    Official Change Log For Naxsi 0.41:-
    Feature: added support for FILE_EXT. We can now control file uploads names/extensions as well.
    Added a rule for FILE_EXT into naxsi_core.rules
    Added unit testing for FILE_EXT feature
    Fixed erroneous log messages
    Fixed an error on whitelist of types $URL:xxx|URL

    To Know More : https://code.google.com/p/naxsi/

    To Download : https://code.google.com/p/naxsi/downloads/list

    OWASP Naxsi Project : https://www.owasp.org/index.php/OWASP_NAXSI_Project

    NAXSI Matrix : https://docs.google.com/spreadsheet/ccc?key=0AjuNPnOoex7SdG5fUkhfc3BCSjJQbVVrQTg4UGU2YVE#gid=0

     NAXSI Presentation : http://www.slideshare.net/phdays/naxsi-an-open-source-waf-for-nginx









    Monday, August 12, 2013

    Useful Online Information Security Portals

    Sandy ( Static & Dynamic Analysis ) : 

             Sandy developed under Indian Honeynet and is capable of doing both static and dynamic analysis of Malicious Office, Jar,HTML files at the moment. 

     

    Two big issues faced by the security industry in general is,
    1. On how to analyze exploits in bulk and extract IP/controller information.
    2. On how to attribute to apt groups to exploits collected.

     

    Sandy Version 1: [Beta testing]

    External: http://exploit-analysis.com
    • Static | Dynamic Analyze Java exploits, Static analysis of Java malwares.
    • Limited support for office file formats.
    • Analysis of url having support for Firefox and IE browsers.
    Sandy To do list:
    • Hpfeeds Integration.
    • Improve performace and analysis for doc samples.
    • Improve stability.
    • Add support for pdf,flash exploits.
    • Dynamic analysis of Java malwares, and Doc files.
    • Add support for pdf/flas files.
    • Add support for Android APK files.
    • In short there need to be a lot of improvement to make it useful :)
    Sandy Snapshot :


    Portal Link : http://www.exploit-analysis.com/sandy/index.php



    HoneyMap :

                  HoneyMap shows a real-time visualization of attacks against the Honeynet Project's sensors deployed around the world. It leverages the internal data sharing protocol hpfeeds as its data source. Read this post to learn about the technical details and frequently asked questions. Before going into explanations, take a look at the map itself: map.honeynet.org

    HoneyMap Snapshot:


    Red markers on the map represent attackers, yellow markers are targets (honeypot sensors).


     Portal Link : http://map.honeynet.org/


    Sicherheitstacho.eu: ( New Real-Time Cyber attack Monitoring System )

                                                This Portal shows statistics of the early warning system of Deutsche Telekom. The corresponding sensors are operated from Deutsche Telekom and Partners,

    Snapshot :



    a cyberattack against an organization from the East Coast of the United States is taking place. If you’re interested in learning such information in real-time, you can check out Sicherheitstacho.eu, a new cyberattack monitoring service launched by Germany’s Deutsche Telekom.

    Besides a real-time overview of current attacks, recorded by a total of 97 sensors, the website also provides statistics such as the top 15 source countries, distribution of attack targets, total number of attacks per day and overall sum of attackers per day.

    Available in English and German, the information presented on the site is gathered from resources such as The Honeynet Project, HoneyMap, Kippo, Glastopf and dionaea.

    Currently, the figures from the site show that a total of 2,402,722 cyberattacks were recorded last month as originating from Russia. Over 900,000 were traced back to Taiwan and 780,000 to Germany.


    Portal Link : http://sicherheitstacho.eu/

    SHODAN : (Sentient Hyper-Optimized Data Access Network)

                Shodan is a computer search engine which scans and searches any online devices such as webcams, routers, printers, iphones etc filtering based on User Agent & Country.SHODAN was created on Earth to serve as the artificial intelligence of the TriOptimum Corporation's research and mining space station Citadel.

    Snapshot :





    Portal Link : http://www.shodanhq.com/

    Thanks .. 




    Wednesday, July 10, 2013

    CAL9000 - Web Application Security Toolkit / Browser

    CAL9000:
                     is a collection of web application security testing tools that complement the feature set of current web proxies and automated scanners. CAL9000 gives you the flexibility and functionality you need for more effective manual testing efforts. Works best when used with Firefox or Internet Explorer.

                       CAL9000 is written in JavaScript, so you have full access to the source code. Feel free to modify it to best suit your particular needs. CAL9000 has some powerful features (like executing cross-domain xmlHttpRequests and writing to disk). It is purposefully designed to do some horribly insecure things. Therefore, I would strongly encourage that you only run it locally and NOT off of a server.



                        CAL9000 is a collection of nine tools that are used to test web applications for security vulnerabilities, specifically cross-site scripting. You can use some of these tools to test other types of vulnerabilities, but the main focus of this toolkit is the cross-site scripting. In this section, we'll take you through the interface CAL9000 and describe each of the below nine tools:


    • XSS Attacks
    • Encode/Decode
    • HTTP Requests
    • HTTP Responses
    • Scratch Pad
    • Cheat Sheets
    • Misc Tools
    • Checklist
    • AutoAttack



                           Show the tool XSS Attacks. This is a dictionary of known XSS Attacks. Click one of the attacks listed in the menu on the left side of the screen, as shown in

     

    Features

    • XSS Attacks - This is a listing of the XSS Attack Info from RSnake. You can filter the listing based on which browsers the attacks work in, test them, apply RegEx filters and create/edit/save/delete your own attacks.
    • Character Encoder/Decoder - Encodes and decodes the following types: URL, Standard Hex, Unicode, Html(Named), Html(Decimal), Html(Hex), Html(Hex Long), Javascript Escaped, XML Escaped, Straight Decimal, Straight Hex, IE Hex, IE Unicode, Base64 and MD5. Encode only with MD4 and SHA1. Specify Upper/Lowercase, Delimiters and Trailing Characters. You can add/remove wrappers around your results and encode/decode selected text instead of the entire contents of the window.
    • Http Requests - Manually craft and send HTTP requests to servers. GET, POST, HEAD, TRACE, TRACK, OPTIONS, CONNECT, PUT, DELETE, COPY, LOCK, MKCOL, MOVE, PROPFIND, PROPPATCH, SEARCH and UNLOCK methods supported. Send single requests or launch automated attacks with more than one request at a time. All results are saved in a history file.
    • Http Responses - View the status codes, response headers and body. Isolate the script, form and cookie information in the response.
    • Scratchpad - A place to save code snippets, notes, results, etc.
    • Cheatsheets - Collection of references for various web-related platforms and languages.
    • IP Encode/Decode - Go to/from IP, Dword, Hex and Octal addresses.
    • String Generator - Create character strings of almost any length.
    • Scroogle Search - A privacy-friendly scrape of Google results w/Advanced Operators.
    • Testing Tips - Collection of testing ideas for assessments.
    • Testing Checklist - Track the progress of your testing efforts and record your findings. The checklist categories roughly correlate with the Manual Testing Techniques from the OWASP Testing Guide. Create/edit/save/delete your own checklist items.
    • AutoAttack Editor - Create/edit/save/delete the AutoAttack Lists that are used to drive the automated multiple-request capabilities on the HTTP Requests page.
    • Store/Restore - Temporarily hold and retrieve textarea and text field contents.
    • Save/Load State - Allows you to save CAL9000 textarea and text field contents and reload them when you are ready to resume testing.
    • Selected Text Processing - Allows you to process selected text inside of a textarea instead of the entire contents. 
    ENCODE/DECODE : 

    HTTP REQUESTS / RESPONSE :

    SCRATCH PAD :

    CHEAT SHEETS :
    MISC TOOLS :

    CHECKLIST :





    AUTOATTACK :




    For more information:

    OWASP CAL9000 Project
    http://www.owasp.org/index.php/Category:OWASP_CAL9000_Project

    http://saei.org/CAL9000/CAL9000/CAL9000.html

    Securing PHP Web Applications
    http://www.informit.com/store/product.aspx?isbn=0321534344

    Web Application Security com CAL9000
    http://www.vivaolinux.com.br/dica/Web-Application-Security-com-CAL9000 


    Download Link : 


    LATEST RELEASE - Version 2.0 released November 16, 2006. See the OWASP CAL9000 Project Roadmap for release notes.



    Monday, June 24, 2013

    OWASP 2013 Top 10 Application Security Risks


    A1-Injection

    Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.


    A2-Broken Authentication and Session Management

    Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities.


    A3-Cross-Site Scripting (XSS)

    XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.


    A4-Insecure Direct Object References

    A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.


    A5-Security Misconfiguration

    Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date.


    A6-Sensitive Data Exposure

    Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.


    A7-Missing Function Level Access Control

    Most web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge requests in order to access functionality without proper authorization.


    A8-Cross-Site Request Forgery (CSRF)

    A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.


    A9-Using Components with Known Vulnerabilities

    Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts.


    A10-Unvalidated Redirects and Forwards

    Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.