N I L A D I C یکشنبه 9 مهر 1396 02:17 ب.ظ نظرات ()
What is a web application?
A web application is an application that runs on a remote server and is accessed through a client. A web app can take the form of services such as Microsoft’s Office 365 or Netflix. The application is presented through a client interface such as a browser or other piece of software.
Web apps are designed to be run across platforms, and native apps
are designed or targeted toward a specific platform or environment.

## types of individuals who will be interacting with a web server:
    * Server Administrators : These individuals are typically concerned with the safety, security,
        and functioning of the web server from an operational standpoint. They try to configure
        the system and remove vulnerabilities before they become problems. For some server
        administrators, this has become an almost impossible task because web servers and the
        applications that run on them have become increasingly complex and powerful, with many
        unknown or undocumented features.
    * Network Administrators : These individuals are concerned with the infrastructure and
        functioning of the network itself as a whole. They look for operational and security issues
        and attempt to deal with them.
    * End Users : Those in this category interact with the web server and application as a
        consumer and user of information. These individuals do not think about the technical
        details as much as getting the services that they desire when they desire them. Making this
        more of an issue is the simple fact that the web browser they are using to access this content
        can allow threats to bypass their or the company’s firewall and have a free ride into the
        internal network.


### The Client and the Server
    Understanding web applications means that you must also examine the interaction
    between client and server that occurs in this environment. A server application is hosted
    on a web server and is designed to be accessed remotely via a web browser or web-enabled
    application. Typically this environment allows for multiple client applications to access the
    server simultaneously, either to retrieve data or to view or modify data. The client performs
    minimal processing of information and typically is optimized to present the information to
    the user. Information is stored on the server.


*** NOTE:
    Web applications are dependent in many cases on the use of technologies
    such as Active Server Pages (ASP), Microsoft ASP.NET, and PHP to allow
    them to function. These technologies are referred to as server-side
    technologies, which means that they process and manipulate information
    on the server. Other technologies such as Dynamic HTML (DHTML),
    JavaScript, and related languages are processed on the client, which puts
    them in the category of client-side technologies.


Most of the commonly encountered web applications are based on the client-server
model and function on a system where data is entered on the client and stored on the server.
Applications such as cloud storage or web-based e-mail services like Yahoo!, Gmail, and
others use this setup as part of their normal functioning.
The past few years have seen the rise of applications for smartphones that perform the
bulk of their processing on the server instead of locally. Google Apps, Microsoft Office
Live, and WebEx WebOffice are examples of the newest generation of web applications.


Web applications are designed to run on web servers and send their output over the
Internet. Let’s examine the running of such applications in their environment.
You can visualize a web application not only as consisting of a client and server, but as
layers. These layers are as follows:

# Presentation Layer : Responsible for the display and presenting of information to the user
    on the client side
# Logic Layer : Used to transform, query, edit, and otherwise manipulate information to and
    from the forms it needs to be stored or presented in
# Data Layer : Responsible for holding the data and information for the application as
    a whole

All of these layers depend on the technology brought to the table in the form of the
World Wide Web, HTML, and HTTP. HTTP is the main protocol used to facilitate
communication between clients and servers, and it operates over port 80. However, other
protocols are sometimes used.

NOTE: HTTPS (HTTP employing encryption mechanisms) can be used to protect
data in transit. This approach is common in applications such as webmail
and e-commerce.

Web applications make heavy use of an underlying web server technology such as
Microsoft’s Internet Information Services (IIS), Apache Server, and Oracle’s iPlanet Web
Server. Resources such as web pages are requested via the stateless HTTP protocol.
Stateless refers to the fact that the protocol does not keep track of session
information from one connection to the next. In fact, each communication
in HTTP is treated as a separate connection. The client provides a uniform resource identifier (URI),
which tells the server what information is being requested and what to return.

Another common component of web applications is the feature known as cookies. A
cookie is a file stored on a client system that is used as a token by applications to store
information of some type (depending on the application). As far as applications are
concerned, cookies are a common element, but from a security standpoint they are viewed
as a liability since they can be easily copied.

NOTE: Cookies emerged as a solution to the problems web developers
experienced with their websites. Cookies allow the owner and developer
of a site to store information on a client system. This information enables
a site to remember the state of the browser as well as store session
information. When a browser is used to visit a site, it will have a cookie
with a unique ID stored on its system. On subsequent visits, this ID will
allow the site to remember the visitor.

Another issue with web applications is vulnerability. No matter how strong the
security policy or standards, every web application is vulnerable to attack and suffers from
flaws. Attacks such as SQL injection, cross-site scripting (XSS), and session hijacking can
take place.


### Pieces of the Web Application Puzzle
In a web application several components exist, each of which serves a specific function.
Each has its own vulnerabilities as well.
    # Login : This component is what is presented to users in order for them to provide a
        username and password for the authentication process.
    # Web Server : This is the foundation for the whole system as it is the combination of
        hardware and software used to host the web application itself. What capabilities the server
        has depends on the type and configuration of the given server.
    # Session Tracking : This component allows the web application to store information about a
        client pertaining to their current visit or future visits to the web application.
    # Permissions : Based on who they authenticate as and if the authentication is successful,
        permissions determine what level of access the user has to resources on the server.
    # Application Content : This is the information that the user is interacting with by providing
        requests to the server.
    # Data Access : Web pages in a web application are attached to a library that provides data
        access.
    # Data Store : This component is where the valuable information for the web application is
        contained. By design this may or may not be stored on the same system.
    # Logic : This component is responsible for interacting with the user and providing the
        means for the correct information to be extracted from the database.
    # Logout : This may be a separate function and is used by users to shut down their
        connection to the web application.


********* Vulnerabilities of Web Servers and Applications:
# Flawed Web Design:
    One common way to exploit a web application or site is in the code itself. Comments and
    hidden tags that are embedded into a web page by the designer can yield information to an
    attacker. Although these types of tags and information are not intended to be displayed in
    a web browser, they can be viewed and analyzed using the View Code or Source capability
    present in most browsers.
    The source code of a page could reveal something like the following:
    <form method="post" action="../../cgi-bin/formMail.pl">
    <!--Regular FormMail options---->
    <input type=hidden name="recipient" value="moblin@termina.com">
    <input type=hidden name="subject" value="Message from website visitor">
    <input type=hidden name="required" value="Name,Email,Address1,City,State,Zip,
    Phone1">
    <input type=hidden name="redirect" value="http://www.termina.com/received.htm">
    <input type=hidden name="servername" value="https://payments.termina.com">
    <input type=hidden name="env_report" value="REMOTE_HOST, HTTP_USER_AGENT">
    <input type=hidden name="title" value="Form Results">
    <input type=hidden name="return_link_url" value="http://www.someplace.com/
    main.html">
    <input type=hidden name="return_link_title" value="Back to Main Page">
    <input type=hidden name="missing_fields_redirect" value="http://www.termina.com/
    error.html">
    <input type=hidden name="orderconfirmation" value="orders@termina.com">
    <input type=hidden name="cc" value="majora@termina.com">
    <input type=hidden name="bcc" value="skullkid@termina.com">
    <!--Courtesy Reply Options-->
    The code contains information that is useful to an attacker. Although the information
    may not be completely actionable, it does give you something. Notice the e-mail addresses
    and even what appears to be a payment processing server ( payments.termina.com ). This is
    information that an attacker can use to target an attack.
    The following is another example of a vulnerability in code that can be exploited:
    <FORM ACTION =http://111.111.111.111/cgi-bin/order.pl" method="post"
    <input type=hidden name="price" value="6000.00">
    <input type=hidden name="prd_id" value="X190">
    QUANTITY: <input type=text name="quant" size=3 maxlength=3 value=1>
    In this example, the application designer has used hidden fields to hold the price of an
    item. Unscrupulous attackers could change the price of the item from $6,000.00 to $60.00
    and make their own discount.
# Buffer Overflow:
    A common vulnerability in web servers, and all software, is buffer overflow. A buffer
    overflow occurs when an application, process, or program attempts to put more data in a
    buffer than it was designed to hold. In practice, buffers should hold only a specific amount
    of data and no more. In the case of a buffer overflow, a programmer, either through
    lazy coding or other practices, creates a buffer in code but does not put restrictions on
    it. The data must go someplace, which in this case means adjacent buffers. When data
    spills or overflows into the buffers it was not intended for, the result can be corrupted
    or overwritten data. If this act occurs, the result can be that data loses its integrity. In
    extreme cases, buffer overwriting can lead to anything from a loss of system integrity to the
    disclosure of information to unauthorized parties.
# Denial-of-Service Attack:
    An attack that can wreak havoc with a web server is the venerable denial-of-service (DoS)
    attack. As a fixed asset, a web server is vulnerable to this attack much as any other server-
    based asset would be. When carried out against a web server, all the resources on that
    server can be rapidly consumed, slowing down its performance. A DoS attack is mostly
    considered an annoyance because it is easy to defeat.
# Distributed Denial-of-Service Attack:
    While a DoS attack is mostly an annoyance, the distributed denial-of-service (DDoS) attack
    is much more of a problem. A DDoS accomplishes the same goal as a DoS: it consumes the
    resources on a server and prevents it from being used by legitimate users. The difference
    between a DDoS and a DoS is scale. In a DDoS, many more systems are used to attack a
    target, crushing it under the weight of multiple requests at once. In some cases, the attack
    can be launched from thousands of servers at once against a target.
    Some of the more common DDoS attacks are:
    * Ping Flooding Attack : A computer sends a ping to another system with the intention of
        uncovering information about the system. This attack can be scaled up so that the packets
        being sent to a target force it to go offline or suffer slowdowns.
    * Smurf Attack : Similar to the ping flood attack, but with a twist to the process. In a Smurf
        attack, a ping command is sent to an intermediate network where it is amplified and
        forwarded to the victim. This single ping now becomes a virtual tsunami of traffic.
    * SYN Flooding : The equivalent of sending a letter that requires a return receipt; however,
        the return address is bogus. If a return receipt is required and the return address is
        bogus, the receipt will go nowhere, and a system waiting for confirmation will be left in
        limbo for some period of time. An attacker that sends enough SYN requests to a system can
        use all the connections on a system so that nothing else can get through.
    * IP Fragmentation/Fragmentation Attack : Requires an attacker to use advanced knowledge
        of the Transmission Control Protocol/Internet Protocol (TCP/IP) suite to break packets up
        into fragments that can bypass most intrusion-detection systems. In extreme cases, this
        type of attack can cause hangs, lockups, reboots, blue screens, and other mischief.
# Banner Information
    As you learned in the footprinting phase, you can gather information from a server by
    performing a banner grab. This process is no different than earlier; you can use tools such as
    telnet or PuTTY to extract banner information and investigate the internals of the service.
    The following code illustrates what may be returned from a banner:
    HTTP/1.1 200 OK
    Server: <web server name and version>
    Content-Location: http://192.168.100.100/index.htm
    Date: Wed, 12 May 2010 14:03:52 GMT
    Content-Type: text/html
    Accept-Ranges: bytes
    Last-Modified: Wed, 12 May 2010 18:56:06 GMT
    ETag: "067d136a639be1:15b6"
    Content-Length: 4325
    This header, which is easy to obtain, reveals information about the server that is being
    targeted. Web servers can have this information sanitized, but the webmaster must actually
    make the effort to do so.
    This information can be returned quite easily from a web server using the following
    command:
    telnet www.<servername>.com 80
# Error Messages
    Error messages can reveal a lot of information about a server and a web application.
    Careless reveals of error messages can provide information that may be used for an attack
    or at least the fine-tuning of an attack. Messages such as the common 404 can inform a
    visitor that content is not available or located on the server. However, there are plenty of
    other error messages that reveal different types of information, from the very detailed to
    the very obscure.
    Fortunately in many servers and applications error messages can be configured or
    suppressed as necessary. Typically these messages should not be too descriptive—if seen at
    all—outside a development or test environment.
# Vandalizing Web Servers
    Web servers are the targets of numerous types of attacks, but one of the most common
    attacks is the act of vandalism known as defacement. Defacing a website can be aggressive
    or subtle, depending on the goals of the attacker, but in either case the goals are the same:
    to embarrass the company, make a statement, or just be a nuisance. To deface a website,
    it is possible to use a number of methods, depending on the attacker’s own skill level,
    capabilities, and opportunities available.
### Common Flaws and Attack Methods:
Let’s take a look at some common ways of attacking a web server and the sites and
applications hosted on them.
# Input Validation:
    Input validation is a mechanism used to verify information as it is entered into an
    application. Essentially, a user entering data into a form or website will have few if
    any restrictions placed on them when they enter data. When data is accepted without
    restriction, mistakes both intentional and unintentional are entered into the system and
    can lead to problems later on. However, with a mechanism for validating input in place it is
    possible to thwart these problems, which include:
         Database manipulation
         Database corruption
         Buffer overflows
         Inconsistent data
    NOTE: A lack of input validation can allow advanced attacks such as SQL injections to occur.

    A good example of input validation, or rather the lack of it, is a box on a form where
    a zip code is to be entered, but in reality it will accept any data. In some cases, taking
    the wrong data will simply mean that the information may be unusable to the owner of the
    site, but it could cause the site to crash or mishandle the information to reveal information
    onscreen.
# Cross-Site Scripting (XSS):
    Another type of attack against a web server is the cross-site scripting (XSS) attack. It relies
    on a variation of the input validation attack, but the target is different because the goal is
    to go after a user instead of the application or data. An example of an XSS uses scripting
    methods to execute a Trojan with a target’s web browser; this would be made possible
    through the use of scripting languages such as JavaScript or VBScript. By careful analysis,
    an attacker can look for ways to inject malicious code into web pages in order to gain
    information from session information on the browser, to elevated access, to content in the
    browser.
    The following steps reveal XSS in action:
    1.      The attacker discovers that a website suffers from an XSS scripting defect.
    2.      An attacker sends an e-mail stating that the victim has just been awarded a prize and
        should collect it by clicking a link in the e-mail:
        The link in the email goes to http://www.badsite.com/default.asp?name=
        <script>badgoal()</script>.
    3.      When the link is clicked, the website displays the message “Welcome Back!” with a
        prompt to enter the name.
        The website has read the name from your browser via the link in the e-mail. When the
        link was clicked in the e-mail the website was told your name is <script>evilScript
        ()</script> .
    4.      The web server reports the name and returns it to the victim’s browser.
    5.      The browser correctly interprets this as script and runs the script.
    6.      This script instructs the browser to send a cookie containing some information to the
        attacker’s system, which it does.
    XSS is an older attack, so many modern browsers include protection
    against it. However, the protection is not foolproof and attacks can in
    fact be induced through poor configuration, patching, or even third-party
    add-ons.
# Insecure Logon Systems:
    Many web applications require some sort of authentication or login process prior to their
    use. Due to the importance of the logon process it is essential that it be handled safely and
    securely. Care must be taken that the incorrect or improper entry of information does not
    reveal information that an attacker can use to gain additional information about a system.
    Applications can track information relating to improper or incorrect logons by users if
    so enabled. Typically, this information comes in log form, with entries listing items such as:
        ■ Entry of an invalid user ID with a valid password
        ■ Entry of an valid user ID with an invalid password
        ■ Entry of an invalid user ID and password
    Applications should be designed to return generic information that does not reveal
    information such as correct usernames. Web apps that return a message such as “username
    invalid” or “password invalid” can give an attacker a target to focus on—such as a correct
    password.
    Performing a Password Crack
    One tool designed to uncover and crack passwords for web applications and websites is
    a utility known as Brutus. Brutus is not a new tool, but it does demonstrate one way an
    attacker can uncover passwords for a website and applications. Brutus is a password cracker
    that is designed to decode different password types present in web applications.
    Brutus is as simple to use as are most tools in this category. Follow these steps:
    1.      Enter the IP address in the Target field in Brutus.
        This is the IP address of the server on which the password is intended to be broken.
    2.      Select the type of password crack to perform in the type field.
        Brutus has the ability to crack passwords using HTTP, FTP, and POP3.
    3.      Enter the port over which to crack the password.
    4.      Configure the Authentication options for the system.
        If the system does not require a username or uses only a password or PIN, choose the
        Use Username option.
        For known usernames, the Single User option may be used and the username entered in
        the box below it.
    5.      Set the Pass Mode and Pass File options.
    Brutus can run the password crack against a dictionary word list.
    At this point, the password-cracking process can begin; once Brutus has cracked the
    password, the Positive Authentication field will display it.
    Brutus is not the newest password cracker in this category, but it is well known and
    effective. Other crackers in this category include THC Hydra.
# Scripting Errors:
    Web applications, programs, and code such as Common Gateway Interface (CGI), ASP
    .NET, and JavaServer Pages (JSP) are commonly in use in web applications and present
    their own issues. Vulnerabilities such as a lack of input validation scripts can be a liability.
    A savvy attacker can use a number of methods to cause grief to the administrator of a web
    application, including the following:
    Upload Bombing : Upload bombing uploads masses of files to a server with the goal
        of filling up the hard drive on the server. Once the hard drive of the server is filled, the
        application will cease to function and will crash.
    Poison Null Byte Attack : A poison null byte attack passes special characters that the
        scripts may not be designed to handle properly. When this is done, the script may grant
        access where it should not otherwise be given.
    Default Scripts : Default scripts are uploaded to servers by web designers who do not know
        what they do at a fundamental level. In such cases, an attacker can analyze or exploit
        configuration issues with the scripts and gain unauthorized access to a system.
    Sample Scripts : Web applications may include sample content and scripts that are regularly
        left in place on servers. In such situations, these scripts may be used by an attacker to carry
        out mischief.
    Poorly Written or Questionable Scripts : Credentials in script source.
# Session Management Issues:
    A session represents the connection that a client has with the server application. The session
    information that is maintained between client and server is important and can give an
    attacker access to confidential information if compromised.
    Ideally a session will have a unique identifier, encryption, and other parameters
    assigned every time a new connection between a client and a server is created. After the
    session is exited, closed, or not needed, the information is discarded and not used again
    (or at least not used for an extended period of time), but this is not always the case. Some
    vulnerabilities of this type include:
    Long-Lived Sessions : Sessions between a client and a server should remain valid only
        for the time they are needed and then discarded. Sessions that remain valid for periods
        longer than they are needed allow intruders using attacks such as XSS to retrieve session
        identifiers and reuse a session.
    Logout Features : Applications should provide a logout feature that allows a visitor to log
        out and close a session without closing the browser.
    Insecure or Weak Session Identifiers : Session IDs that are easily predicted or guessed—so
        they can be used by an attacker to retrieve or use sessions that should be closed—can be
        exploited. Some flaws in web applications can lead to the reuse of session IDs. Exploitation
        of session IDs can also fall into the category of session hijacking.
    Granting of Session IDs to Unauthorized Users : Sometimes applications grant session IDs
        to unauthenticated users and redirect them to a logout page. This can give the attacker the
        ability to request valid URLs.
    Poor or No Password Change Controls : An improperly implemented or insecure password
        change system, in which the old password is not required, allows a hacker to change
        passwords of other users.
    Inclusion of Unprotected Information in Cookies : Cookies may contain unprotected
        information such as the internal IP address of a server that can be used by a hacker to learn
        more about the nature of the web application.
# Encryption Weaknesses:
    In web applications, encryption plays a vital role because sensitive information is frequently
    exchanged between client and server in the form of logons or other types of information.
    When working on securing web applications, you must consider the safety of
    information at two stages: when it is being stored and when it is transmitted. Both
    stages are potential areas for attack. When considering encryption and its impact on the
    application, focus on these areas of concern:
    Weak Ciphers : Weak ciphers or encoding algorithms are those that use short keys or
        are poorly designed and implemented. Use of such weak ciphers can allow an attacker to
        decrypt data easily and gain unauthorized access to the information.
    Vulnerable Software : Some software implementations that encrypt the transmission of
        data, such as Secure Sockets Layer (SSL), may suffer from poor programming and thus
        become vulnerable to attacks such as buffer overflows.
        Some tools and resources are available to help in assessing the security of web
        applications and their associated encryption strategies:
        ■ OpenSSL, an open source toolkit used to implement the SSLv3 and TLS v1 protocols:
            www.openssl.org
        ■ The OWASP guide to common cryptographic flaws: www.owasp.org
        ■ Nessus Vulnerability Scanner, which can list the ciphers in use by a web server: www.nessus.org
        ■ WinSSLMiM, which can be used to perform an HTTPS man-in-the-middle attack:
            www.securiteinfo.com/outils/WinSSLMiM.shtml
        ■ Stunnel, a program that allows the encryption of non-SSL-aware protocols:
            www.stunnel.org
# Directory Traversal Attacks:
    Another type of attack is the directory traversal attack, which allows an attacker to move
    outside of the web server directory and into other parts of the host system. Once outside
    this directory, the attacker may then be able to bypass permissions and other security
    controls and execute commands on the system.
    To execute this attack, an intruder takes advantage of errors or weaknesses in one of
    two areas
        ■ Access control lists (ACLs), which are used to indicate which users and groups are
            allowed to access files and directories on a server as well as what level of interaction is
            allowed.
        ■ Root directory, which is the directory on the server to which users are specifically
            restricted. Typically this is the highest-level folder they are allowed to access. The
            root directory acts as the top directory in the website and prevents users from gaining
            access to sensitive files on the server.
    To perform a directory traversal attack, surprisingly little is needed—just some knowledge
    and a web browser. With these tools and patience, it is possible to blindly find default
    files and directories on a system.
    The success of the attack depends largely on the configuration of the website and server,
    but there are some common threads. Typically the attackers rely on taking over or spoofing
    themselves as a user and gaining access to anything the user has access to.
    In web applications with dynamic pages (such as ASP or ASP.NET), input is usually
    received from browsers through GET or POST request methods. Here is an example of a
    GET HTTP request URL:
    http://beta.canadiens.com/show.asp?view=history.html
    With this URL, the browser requests the dynamic page show.asp from the server and with
    it also sends the parameter view with the value history.html . When this request is executed
    on the web server, show.asp retrieves the file history.html from the server’s filesystem and
    returns it to the requesting party. Through some analysis an attacker can assume that the
    page show.asp can retrieve files from the filesystem and craft a custom URL:
    http://beta.canadiens.com/show.asp?view=../../../../../Windows/system.ini
    This will cause the dynamic page to retrieve the file system.ini from the filesystem and
    display it to the user. The expression ../ instructs the system to go one directory up, which
    is commonly used as an operating system directive. The attacker has to guess how many
    directories to go up to find the Windows folder on the system, but this is easily done by
    trial and error.

    IMP NOTE:The actual directory structure will vary depending on the server itself, so
    this process may require a considerable amount of trial and error. However
    consider the fact that it is not uncommon for software to be installed into
    default folders and structures.

    Of course, you don’t need to use code to attack the server; you can use just the browser
    alone. A web server may be completely open to a directory traversal attack and only
    waiting for an ambitious attacker to track down and use sample files and scripts against it.
    For example, a URL request that makes use of the scripts directory of IIS to traverse
    directories and execute a command can look like this:
    http://server.com/scripts/..\../Windows/System32/cmd.exe?/c+dir+c:\
    The request returns a list of all files in the C:\ directory by executing the cmd.exe
    command shell file and running the command dir c:\ in the shell. The \ expression that
    is in the URL request is a web server escape code used to represent normal characters. In
    this case \ represents the character \ .
# Directory Traversal Attack Countermeasures:
    A handful of methods can be used to thwart directory traversal attacks, such as:
        ■ Running modern web server software or ensuring that up-to-date patches are installed.
        ■ Enabling filtering of user input to the web server. It is common for modern web servers
            to include the ability to filter out nonstandard requests or codes.