validators.xml. Multiple validation definitions with the same name may result in unexpected behavior.expose_php option is enabled, every response produced by the PHP interpreter includes the version of PHP installed on the host system. Armed with the version of PHP running on the remote server, an attacker may enumerate the known exploits against the system, which can greatly lower the cost of mounting a successful attack.ExternalInterface, fscommand or getURL. XML.load, loadVariables, LoadVars.load etc. If a Flash application should not communicate with the browser or needs to make any networking calls, the AllowNetworkingAccess tag must be set to "none".AllowNetworkingAccess tag must be set to "none". AllowNetworkingAccess tag should be set to "internal". AllowNetworkingAccess tag must be set to "all". EnableSensitiveDataLogging option to true which allows application data used in database commands to be included in logging and exception messages.
...
services.AddDbContext<ApplicationDbContext>(options => {
options.UseSqlServer(_configuration.GetConnectionString("ApplicationDbConnection"));
options.EnableSensitiveDataLogging(true);
});
...
log4j.properties file causes all queries to be logged at the info level.
...
log4j.logger.net.sf.hibernate.type=info
log4j.logger.net.sf.hibernate.tool.hbm2ddl=info
...
dest request parameter when a user clicks the link.
...
DATA: str_dest TYPE c.
str_dest = request->get_form_field( 'dest' ).
response->redirect( str_dest ).
...
Example 1 will redirect the browser to "http://www.wilyhacker.com".dest request parameter when a user clicks the link.
...
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var strDest:String = String(params["dest"]);
host.updateLocation(strDest);
...
Example 1 will redirect the browser to "http://www.wilyhacker.com".PageReference object consisting of a URL from the dest request parameter.
public PageReference pageAction() {
...
PageReference ref = ApexPages.currentPage();
Map<String,String> params = ref.getParameters();
return new PageReference(params.get('dest'));
}
Example 1 will redirect the browser to "http://www.wilyhacker.com".dest request parameter when a user clicks the link.
String redirect = Request["dest"];
Response.Redirect(redirect);
Example 1 will redirect the browser to "http://www.wilyhacker.com".dest request parameter when a user clicks the link.
...
final server = await HttpServer.bind(host, port);
await for (HttpRequest request in server) {
final response = request.response;
final headers = request.headers;
final strDest = headers.value('strDest');
response.headers.contentType = ContentType.text;
response.redirect(Uri.parse(strDest!));
await response.close();
}
...
Example 1 will redirect the browser to "http://www.wilyhacker.com".dest request parameter when a user clicks the link.
...
strDest := r.Form.Get("dest")
http.Redirect(w, r, strDest, http.StatusSeeOther)
...
Example 1 redirects the browser to "http://www.wilyhacker.com".dest request parameter when a user clicks the link.
<end-state id="redirectView" view="externalRedirect:#{requestParameters.dest}" />
Example 1 will redirect the browser to "http://www.wilyhacker.com".dest request parameter when a user clicks the link.
...
strDest = form.dest.value;
window.open(strDest,"myresults");
...
Example 1 will redirect the browser to "http://www.wilyhacker.com".dest request parameter when a user clicks the link.
<%
...
$strDest = $_GET["dest"];
header("Location: " . $strDest);
...
%>
Example 1 will redirect the browser to "http://www.wilyhacker.com".dest request parameter when a user clicks the link.
...
-- Assume QUERY_STRING looks like dest=http://www.wilyhacker.com
dest := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 6);
OWA_UTIL.redirect_url('dest');
...
Example 1 will redirect the browser to "http://www.wilyhacker.com".dest request parameter when a user clicks the link.
...
strDest = request.field("dest")
redirect(strDest)
...
Example 1 will redirect the browser to "http://www.wilyhacker.com".dest request parameter:
...
str_dest = req.params['dest']
...
res = Rack::Response.new
...
res.redirect("http://#{dest}")
...
Example 1 will redirect the browser to "http://www.wilyhacker.com".dest request parameter.
def myAction = Action { implicit request =>
...
request.getQueryString("dest") match {
case Some(location) => Redirect(location)
case None => Ok("No url found!")
}
...
}
Example 1 will redirect the browser to "http://www.wilyhacker.com".requestToLoad to point to the original URL's "dest" parameter if it exists and to the original URL using the http:// scheme otherwise, and finally loads this request within a WKWebView:
...
let requestToLoad : String
...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
if let urlComponents = NSURLComponents(URL: url, resolvingAgainstBaseURL: false) {
if let queryItems = urlComponents.queryItems as? [NSURLQueryItem]{
for queryItem in queryItems {
if queryItem.name == "dest" {
if let value = queryItem.value {
request = NSURLRequest(URL:NSURL(string:value))
requestToLoad = request
break
}
}
}
}
if requestToLoad == nil {
urlComponents.scheme = "http"
requestToLoad = NSURLRequest(URL:urlComponents.URL)
}
}
...
}
...
...
let webView : WKWebView
let appDelegate = UIApplication.sharedApplication().delegate as! AppDelegate
webView.loadRequest(appDelegate.requestToLoad)
...
Example 1 will attempt to request and load "http://www.wilyhacker.com" in the WKWebView.dest request parameter when a user clicks the link.
...
strDest = Request.Form('dest')
HyperLink.NavigateTo strDest
...
Example 1 will redirect the browser to "http://www.wilyhacker.com".lm.requestLocationUpdates(LocationManager.GPS_PROVIDER, 1000, 0, locationListener);
FLAG_GRANT_READ_URI_PERMISSION and FLAG_GRANT_WRITE_URI_PERMISSION. If a malicious program is able to intercept this intent, it will then gain permission to read from or write to the specified URI. These can often be more susceptible to being intercepted if the intent is implicit rather than explicit.
myIntent.setFlags(Intent.FLAG_GRANT_WRITE_URI_PERMISSION);
Cache-Control: public would instruct the browser to persistently cache the content on the hard drive. Caching can be prevented by specifying one of the following three directives in the response headersCache-control: privateCache-Control: no-cacheCache-Control: no-storeUseHttpLogging() method adds HTTP logging middleware to the middleware pipeline which allows middleware components to log. When specified in the wrong order as shown, no middleware added to the pipeline before the call to UseHttpLogging() will log.Example 2: The
...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
...
}
app.UseHttpLogging();
...
UseWC3Logging() method adds W3C logging middleware to the middleware pipeline which allows middleware components to log. When specified in the wrong order as shown, no middleware added to the pipeline before the call to UseWC3Logging() will log.
...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
...
}
app.UseWC3Logging();
...
sms.sendTextMessage(recipient, null, message, PendingIntent.getBroadcast(SmsMessaging.this, 0, new Intent(ACTION_SMS_SENT), 0), null);
number = tm.getCompleteVoiceMailNumber();
<authorization>
<allow verbs="GET,POST" users="admin"/>
<deny verbs="GET,POST"users="*" />
</authorization>
<security-constraint>
<display-name>Admin Constraint</display-name>
<web-resource-collection>
<web-resource-name>Admin Area</web-resource-name>
<url-pattern>/pages/index.jsp</url-pattern>
<url-pattern>/admin/*.do</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<description>only admin</description>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
<http-method> tag in this configuration, it might be possible to exercise administrative functionality by substituting GET or POST requests with HEAD requests. For HEAD requests to exercise administrative functionality, condition 3 must hold - the application must carry out commands based on verbs other than POST. Some web/application servers will accept arbitrary non-standard HTTP verbs and respond as if they were given a GET request. If that is the case, an attacker would be able to view administrative pages by using an arbitrary verb in a request.
GET /admin/viewUsers.do HTTP/1.1
Host: www.example.com
FOO /admin/viewUsers.do HTTP/1.1
Host: www.example.com
Access-Control-Allow-OriginAccess-Control-Allow-HeadersAccess-Control-Allow-MethodsAccess-Control-Max-Ageeid, from an HTTP request and displays it to the user.
String eid = Request["eid"];
...
EmployeeID.Text = eid;
EmployeeID is a server-side ASP.NET control defined as follows:
<form runat="server">
...
<asp:Label id="EmployeeID" runat="server"/>
...
</form>
eid contains only standard alphanumeric text. If eid has a value that includes metacharacters or source code, then the code is executed by the web browser as it displays the HTTP response.
...
string name = "";
using (SqlConnection conn = new SqlConnection(_ConnectionString))
{
string eid = Request["eid"];
SqlCommand cmd = new SqlCommand("SELECT * FROM emp WHERE id = @id", conn);
cmd.Parameters.AddWithValue("@id", eid);
conn.Open();
SqlDataReader objReader = cmd.ExecuteReader();
while (objReader.Read())
{
name = objReader["name"];
}
objReader.Close();
}
...
EmployeeName.Text = name;
EmployeeName is a server-side ASP.NET control defined as follows:
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server"/>
...
</form>
Example 2, this code functions correctly when the values of name are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of name is read from a database, whose contents are apparently managed by the application. However, if the value of name originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker may execute malicious commands in the user's web browser. This type of exploit, known as Persistent (or Stored) XSS, is particularly insidious because the indirection caused by the data store makes it difficult to identify the threat and increases the possibility that the attack might affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.Example 1, data is read directly from the HTTP request and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or emailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that might include session information, from the user's machine to the attacker or perform other nefarious activities.Example 2, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Persistent XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.user, from an HTTP request and displays it to the user.
func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
user := r.FormValue("user")
...
fmt.Fprintln(w, "Username is: ", user)
}
user contains only standard alphanumeric text. If user has a value that includes metacharacters or source code, then the code will be executed by the web browser as it displays the HTTP response.
func someHandler(w http.ResponseWriter, r *http.Request){
...
row := db.QueryRow("SELECT name FROM users WHERE id =" + userid)
err := row.Scan(&name)
...
fmt.Fprintln(w, "Username is: ", name)
}
Example 1, this code functions correctly when the values of name are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of name is read from a database, whose contents are apparently managed by the application. However, if the value of name originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker can execute malicious commands in the user's web browser. This type of exploit, known as Persistent (or Stored) XSS, is particularly insidious because the indirection caused by the data store makes it difficult to identify the threat and increases the possibility that the attack affects multiple users. XSS began in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.Example 1, data is read directly from the HTTP request and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or emailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that might include session information, from the user's machine to the attacker or perform other nefarious activities.Example 2, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Persistent XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker can perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.
...
WebView webview = (WebView) findViewById(R.id.webview);
webview.getSettings().setJavaScriptEnabled(true);
String url = this.getIntent().getExtras().getString("url");
webview.loadUrl(url);
...
url starts with javascript:, JavaScript code that follows executes within the context of the web page inside WebView.eid, from an HTTP request and displays it to the user.
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
eid contains only standard alphanumeric text. If eid has a value that includes metacharacters or source code, then the code is executed by the web browser as it displays the HTTP response.
<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
}
%>
Employee Name: <%= name %>
Example 2, this code functions correctly when the values of name are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of name is read from a database, whose contents are apparently managed by the application. However, if the value of name originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker may execute malicious commands in the user's web browser. This type of exploit, known as Persistent (or Stored) XSS, is particularly insidious because the indirection caused by the data store makes it difficult to identify the threat and increases the possibility that the attack might affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.Example 1, a source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.Example 2, data is read directly from the HTTP request and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or emailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that might include session information, from the user's machine to the attacker or perform other nefarious activities.Example 3, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Persistent XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.
...
val webview = findViewById<View>(R.id.webview) as WebView
webview.settings.javaScriptEnabled = true
val url = this.intent.extras!!.getString("url")
webview.loadUrl(url)
...
url starts with javascript:, JavaScript code that follows executes within the context of the web page inside WebView.eid, from an HTTP servlet request, then displays the value back to the user in the servlet's response.
val eid: String = request.getParameter("eid")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee ID: $eid")
...
out.close()
...
eid contains only standard alphanumeric text. If eid has a value that includes metacharacters or source code, then the code is executed by the web browser as it displays the HTTP response.
val stmt: Statement = conn.createStatement()
val rs: ResultSet = stmt.executeQuery("select * from emp where id=$eid")
rs.next()
val name: String = rs.getString("name")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee Name: $name")
...
out.close()
...
Example 2, this code functions correctly when the values of name are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of name is read from a database, whose contents are apparently managed by the application. However, if the value of name originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker may execute malicious commands in the user's web browser. This type of exploit, known as Persistent (or Stored) XSS, is particularly insidious because the indirection caused by the data store makes it difficult to identify the threat and increases the possibility that the attack might affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.Example 1, a source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.Example 2, data is read directly from the HTTP request and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or emailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that might include session information, from the user's machine to the attacker or perform other nefarious activities.Example 3, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Persistent XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.
...
@property (strong, nonatomic) NSString *webContentFromURL;
...
- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation {
...
[self setWebContentFromURL:[url host]];
...
...
...
@property (strong, nonatomic) WKWebView *webView;
...
AppDelegate *appDelegate = (AppDelegate *)[[UIApplication sharedApplication] delegate];
...
[_webView loadHTMLString:appDelegate.webContentFromURL] baseURL:nil];
...
...
@property (strong, nonatomic) WKWebView *webView;
@property (strong, nonatomic) UITextField *inputTextField;
...
[_webView loadHTMLString:_inputTextField.text baseURL:nil];
...
inputTextField contains only standard alphanumeric text. If the text within inputTextField includes metacharacters or source code, then the input may be executed as code by the web browser as it displays the HTTP response.
...
@property (strong, nonatomic) WKWebView *webView;
...
NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
NSEntityDescription *entity = [NSEntityDescription entityForName:@"Employee" inManagedObjectContext:context];
[fetchRequest setEntity:entity];
NSArray *fetchedObjects = [context executeFetchRequest:fetchRequest error:&error];
for (NSManagedObject *info in fetchedObjects) {
NSString msg = @"Hello, " + [info valueForKey:@"name"];
[_webView loadHTMLString:msg baseURL:nil]
...
}
...
Example 2, this code functions correctly when the values of name are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of name is read from a database, whose contents are apparently managed by the application. However, if the value of name originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker may execute malicious commands in the user's web browser. This type of exploit, known as Persistent (or Stored) XSS, is particularly insidious because the indirection caused by the data store makes it difficult to identify the threat and increases the possibility that the attack might affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.Example 1, a source outside the target application makes a URL request using the target application's custom URL scheme, and unvalidated data from the URL request subsequently read back into the application as trusted data and included in dynamic content.Example 2, data is read directly from a user-controllable UI component and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or emailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that might include session information, from the user's machine to the attacker or perform other nefarious activities.Example 3, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Persistent XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.
...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let name = getQueryStringParameter(url.absoluteString, "name")
let html = "Hi \(name)"
let webView = WKWebView()
webView.loadHTMLString(html, baseURL:nil)
...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
return queryItems.filter({ (item) in item.name == param }).first?.value!
}
return nil
}
...
loadHTMLString: is user-controllable and JavaScript is enabled by default within a WKWebView, the user can write arbitrary content (including executable scripts) to the WKWebView via requests that use app's custom URL scheme.
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
inputTextField contains only standard alphanumeric text. If the text within inputTextField includes metacharacters or source code, then the input may be executed as code by the web browser as it displays the HTTP response.
let fetchRequest = NSFetchRequest()
let entity = NSEntityDescription.entityForName("Employee", inManagedObjectContext: managedContext)
fetchRequest.entity = entity
do {
let results = try managedContext.executeFetchRequest(fetchRequest)
let result : NSManagedObject = results.first!
let name : String = result.valueForKey("name")
let msg : String = "Hello, \(name)"
let webView : UIWebView = UIWebView()
webView.loadHTMLString(msg, baseURL:nil)
} catch let error as NSError {
print("Error \(error)")
}
Example 2, this code functions correctly when the values of name are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of name is read from a database, whose contents are apparently managed by the application. However, if the value of name originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker may execute malicious commands in the user's web browser. This type of exploit, known as Persistent (or Stored) XSS, is particularly insidious because the indirection caused by the data store makes it difficult to identify the threat and increases the possibility that the attack might affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.Example 1, a source outside the target application makes a URL request using the target application's custom URL scheme, and unvalidated data from the URL request subsequently read back into the application as trusted data and included in dynamic content.Example 2, data is read directly from a user-controllable UI component and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or emailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that might include session information, from the user's machine to the attacker or perform other nefarious activities.Example 3, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Persistent XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.
<form-validation>
<formset>
<form name="ProjectForm">
...
</form>
<form name="ProjectForm">
...
</form>
</formset>
</form-validation>
ActionForm class. One indication that validation logic is not being properly maintained is inconsistencies between the action form and the validation form.
public class DateRangeForm extends ValidatorForm {
String startDate, endDate;
public void setStartDate(String startDate) {
this.startDate = startDate;
}
public void setEndDate(String endDate) {
this.endDate = endDate;
}
}
startDate and endDate.
<form name="DateRangeForm">
<field property="startDate" depends="date">
<arg0 key="start.date"/>
</field>
<field property="endDate" depends="date">
<arg0 key="end.date"/>
</field>
<field property="scale" depends="integer">
<arg0 key="range.scale"/>
</field>
</form>
scale. The presence of the third field suggests that DateRangeForm was modified without taking validation into account.