Perform a Functional Analysis
Another critical step in the methodology is the actual analysis of each individual function
of the application. The essence of functional analysis is identifying each component function
of the application (for example, order input, confirmation, and order tracking) and
attempting to inject faults into each input receptacle. This process of attempted fault injection
is central to software security testing, and is sometimes referred to as input validation
attacks,
Exploit the Data Connectivity
Some of the most devastating attacks on Web applications actually relate to the back-end
database. After all, that’s usually where all of the juicy customer data is stored anyway,
right? Because of the myriad of ways available to connect Web applications with databases,
Web developers tend to focus on the most efficient way to make this connection,
rather than the most secure. We’ll cover some of the classic methods for extracting
data—and even using SQL to take control of the operating system
Attack the Management Interfaces
Until now, we haven’t discussed one of the other essential services that typically runs on
or around Web applications: remote management. Web sites run 24/7, which means that
it’s not always feasible for the Webmaster to be sitting in the data center when something
needs updating or fixing. Combined with the natural propensity of Web folk for remote
telework (no dress code required), it’s a good bet that any given Web application architecture
has a port open somewhere to permit remote maintenance of servers, content,
back-end databases, and so on.
In addition, just about every networking product (hardware or software) that has
been produced since the mid-’90s likely shipped with a Web-based management interface
running on an embedded Web server
Attack the Client
In many years of professional Web application testing, we’ve seen darn few reviews take
appropriate time to consider attacks against the client side of the Web application architecture.
This is a gross oversight in our estimation, since there have been some devastating
attacks against the Web user community over the years, including cross-site scripting
ploys, like those published for eBay, E*Trade, and Citigroup’s Web sites, as well as
Internet-born worms like Nimda that could easily be implemented within a rogue Web
site and mailed out via URL to millions of people, or posted to a popular newsgroup, or
forwarded via online chat
Launch a Denial-of-Service Attack
Assuming that an attacker hasn’t gotten in at this point in the methodology, the last refuge
of a defeated mind is denial of service (DoS), a sad but true component of today’s
Internet. As its name suggests, DoS describes the act of denying Web application functionality
to legitimate users. It is typically carried out by issuing a flood of traffic to a site,
drowning out legitimate requests
Another critical step in the methodology is the actual analysis of each individual function
of the application. The essence of functional analysis is identifying each component function
of the application (for example, order input, confirmation, and order tracking) and
attempting to inject faults into each input receptacle. This process of attempted fault injection
is central to software security testing, and is sometimes referred to as input validation
attacks,
Exploit the Data Connectivity
Some of the most devastating attacks on Web applications actually relate to the back-end
database. After all, that’s usually where all of the juicy customer data is stored anyway,
right? Because of the myriad of ways available to connect Web applications with databases,
Web developers tend to focus on the most efficient way to make this connection,
rather than the most secure. We’ll cover some of the classic methods for extracting
data—and even using SQL to take control of the operating system
Attack the Management Interfaces
Until now, we haven’t discussed one of the other essential services that typically runs on
or around Web applications: remote management. Web sites run 24/7, which means that
it’s not always feasible for the Webmaster to be sitting in the data center when something
needs updating or fixing. Combined with the natural propensity of Web folk for remote
telework (no dress code required), it’s a good bet that any given Web application architecture
has a port open somewhere to permit remote maintenance of servers, content,
back-end databases, and so on.
In addition, just about every networking product (hardware or software) that has
been produced since the mid-’90s likely shipped with a Web-based management interface
running on an embedded Web server
Attack the Client
In many years of professional Web application testing, we’ve seen darn few reviews take
appropriate time to consider attacks against the client side of the Web application architecture.
This is a gross oversight in our estimation, since there have been some devastating
attacks against the Web user community over the years, including cross-site scripting
ploys, like those published for eBay, E*Trade, and Citigroup’s Web sites, as well as
Internet-born worms like Nimda that could easily be implemented within a rogue Web
site and mailed out via URL to millions of people, or posted to a popular newsgroup, or
forwarded via online chat
Launch a Denial-of-Service Attack
Assuming that an attacker hasn’t gotten in at this point in the methodology, the last refuge
of a defeated mind is denial of service (DoS), a sad but true component of today’s
Internet. As its name suggests, DoS describes the act of denying Web application functionality
to legitimate users. It is typically carried out by issuing a flood of traffic to a site,
drowning out legitimate requests
No comments:
Post a Comment