Trace.Warn 3 Trace shoud be disabled in production enviroment. And should be used only for debugging. Ensure you are not providing sensitive informations. http://www.owasp.org System.Diagnostic.Process.Start 3 This k_name may be vulnerable to command injection attacks or OS injection attacks. Java linking to the native OS can cause serious issues and potentially give rise to total server compromise. http://www.owasp.org delete 3 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org exec sp_executesql 3 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org delete from where 3 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org exec sp_ 3 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org exec xp_ 3 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org exec @ 3 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org executestatement 3 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org executeSQL 3 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org driver 3 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org <meta> 3 Many of the HTML tags below can be used for client side attacks such as cross site scripting. It is important to examine the context in which these tags are used and to examine any relevant data validation associated with the display. http://www.owasp.org request.certificate 3 Requests from external sources are obviously a key area of a secure code review. We http://www.owasp.org request.cookie 3 Requests from external sources are obviously a key area of a secure code review. We http://www.owasp.org request.form 3 Requests from external sources are obviously a key area of a secure code review. We http://www.owasp.org request.querystring 3 Requests from external sources are obviously a key area of a secure code review. We http://www.owasp.org java.sql.Statement.executeQuery 3 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org java.sql.Statement.executeUpdate 3 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org javax.servlet.jsp.JspWriter.print 3 Can lead to Cross site Scripting http://www.owasp.org javax.servlet.ServletOutputStream.print 3 Can lead to Cross Site Scripting http://www.owasp.org javax.servlet.http.Cookie 3 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org javax.servlet. 3 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org <body> 3 Many of the HTML tags below can be used for client side attacks such as cross site scripting. It is important to examine the context in which these tags are used and to examine any relevant data validation associated with the display. http://www.owasp.org <object> 3 Many of the HTML tags below can be used for client side attacks such as cross site scripting. It is important to examine the context in which these tags are used and to examine any relevant data validation associated with the display. http://www.owasp.org DataSource 2 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org New OleDbConnection 2 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org ADODB.recordset 2 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org .Open 2 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org .Provider 2 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org Server.CreateObject 2 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org ReflectionPermission.MemberAccess 2 Bypassing the code access security permission? Not a good idea. This keyword is a part of a list of potentially dangerous permissions such as calling unmanaged code, outside the CLR. http://www.owasp.org sql server 2 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org sqloledb 2 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org adodb 2 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org GetQueryResultInXML 2 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org enableViewState 2 It is important that many variables in machine.config can be overridden in the web.config file for a particular application. http://www.owasp.org setfilter 2 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org SqlCommand 2 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org Microsoft.Jet 2 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org SqlDataReader 2 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org GetString 2 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org SqlDataAdapter 2 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org CommandType 2 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org StoredProcedure 2 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org System.Data.Sql 2 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org <applet> 2 Many of the HTML tags below can be used for client side attacks such as cross site scripting. It is important to examine the context in which these tags are used and to examine any relevant data validation associated with the display. http://www.owasp.org RC2 2 If cryptography is used then is a strong enough cipher used i.e. AES or 3DES. What size key is used, the larger the better. Where is hashing performed. Are password that are being persisted hashed, they should be. How are random numbers generated? is the PRNG "random enough"? http://www.owasp.org System.Random 2 If cryptography is used then is a strong enough cipher used i.e. AES or 3DES. What size key is used, the larger the better. Where is hashing performed. Are password that are being persisted hashed, they should be. How are random numbers generated? is the PRNG "random enough"? http://www.owasp.org Random 2 If cryptography is used then is a strong enough cipher used i.e. AES or 3DES. What size key is used, the larger the better. Where is hashing performed. Are password that are being persisted hashed, they should be. How are random numbers generated? is the PRNG "random enough"? http://www.owasp.org System.Security.Cryptography 2 If cryptography is used then is a strong enough cipher used i.e. AES or 3DES. What size key is used, the larger the better. Where is hashing performed. Are password that are being persisted hashed, they should be. How are random numbers generated? is the PRNG "random enough"? http://www.owasp.org <ilayer> 2 Many of the HTML tags below can be used for client side attacks such as cross site scripting. It is important to examine the context in which these tags are used and to examine any relevant data validation associated with the display. http://www.owasp.org ProtectedMemory 2 If storing sensitive data in memory recommend one uses the following. http://www.owasp.org HttpOnly 2 Cookie manipulation can be key to various application security exploits such as session hijacking/fixation and parameter manipulation. One should examine any code relating to cookie functionalty as this would have a bearing on session security. http://www.owasp.org System.NET.Cookie 2 Cookie manipulation can be key to various application security exploits such as session hijacking/fixation and parameter manipulation. One should examine any code relating to cookie functionalty as this would have a bearing on session security. http://www.owasp.org <frame security 2 Many of the HTML tags below can be used for client side attacks such as cross site scripting. It is important to examine the context in which these tags are used and to examine any relevant data validation associated with the display. http://www.owasp.org <iframe security 2 Many of the HTML tags below can be used for client side attacks such as cross site scripting. It is important to examine the context in which these tags are used and to examine any relevant data validation associated with the display. http://www.owasp.org system.web.ui.htmlcontrols.htmlinputhidden 2 The input controls below are server classes used to produce and display web application form fields. Looking for such references helps locate entry points into the application. http://www.owasp.org system.web.ui.webcontrols.textbox 2 The input controls below are server classes used to produce and display web application form fields. Looking for such references helps locate entry points into the application. http://www.owasp.org system.web.ui.webcontrols.listbox 2 The input controls below are server classes used to produce and display web application form fields. Looking for such references helps locate entry points into the application. http://www.owasp.org system.web.ui.webcontrols.checkboxlist 2 The input controls below are server classes used to produce and display web application form fields. Looking for such references helps locate entry points into the application. http://www.owasp.org system.web.ui.webcontrols.dropdownlist 2 The input controls below are server classes used to produce and display web application form fields. Looking for such references helps locate entry points into the application. http://www.owasp.org requestEncoding 2 The .NET Framework relies on .config files to define configuration settings. The .config files are text-based XML files. Many .config files can, and typically do, exist on a single system. Web applications refer to a web.config file located in the application's root directory. For ASP.NET applications, web.config information about most aspects of the application's operation. http://www.owasp.org responseEncoding 2 The .NET Framework relies on .config files to define configuration settings. The .config files are text-based XML files. Many .config files can, and typically do, exist on a single system. Web applications refer to a web.config file located in the application's root directory. For ASP.NET applications, web.config information about most aspects of the application's operation. http://www.owasp.org trace 2 The .NET Framework relies on .config files to define configuration settings. The .config files are text-based XML files. Many .config files can, and typically do, exist on a single system. Web applications refer to a web.config file located in the application's root directory. For ASP.NET applications, web.config information about most aspects of the application's operation. http://www.owasp.org authorization 2 The .NET Framework relies on .config files to define configuration settings. The .config files are text-based XML files. Many .config files can, and typically do, exist on a single system. Web applications refer to a web.config file located in the application's root directory. For ASP.NET applications, web.config information about most aspects of the application's operation. http://www.owasp.org CustomErrors 2 The .NET Framework relies on .config files to define configuration settings. The .config files are text-based XML files. Many .config files can, and typically do, exist on a single system. Web applications refer to a web.config file located in the application's root directory. For ASP.NET applications, web.config information about most aspects of the application's operation. http://www.owasp.org httpRuntime 2 The .NET Framework relies on .config files to define configuration settings. The .config files are text-based XML files. Many .config files can, and typically do, exist on a single system. Web applications refer to a web.config file located in the application's root directory. For ASP.NET applications, web.config information about most aspects of the application's operation. http://www.owasp.org maxRequestLength 2 The .NET Framework relies on .config files to define configuration settings. The .config files are text-based XML files. Many .config files can, and typically do, exist on a single system. Web applications refer to a web.config file located in the application's root directory. For ASP.NET applications, web.config information about most aspects of the application's operation. http://www.owasp.org forms protection 2 The .NET Framework relies on .config files to define configuration settings. The .config files are text-based XML files. Many .config files can, and typically do, exist on a single system. Web applications refer to a web.config file located in the application's root directory. For ASP.NET applications, web.config information about most aspects of the application's operation. http://www.owasp.org appSettings 2 The .NET Framework relies on .config files to define configuration settings. The .config files are text-based XML files. Many .config files can, and typically do, exist on a single system. Web applications refer to a web.config file located in the application's root directory. For ASP.NET applications, web.config information about most aspects of the application's operation. http://www.owasp.org Insert 2 Please provide a description for this item http://www.owasp.org ValidateRequest 2 Logging can be a source of information leakage. It is important to examine all calls to the logging subsystem and to determinate if any sensitive information is being logged. Commomon mistakes are logging userID in conjuction with passwords within the authentication functionality or logging database requests which may contains sensitive data. http://www.owasp.org ObjectInputStream 2 This command are generally used to read data into ones application. They may be potential entry points into application. The entry points may be from an external source and must be inverstigated. Can be also used in path traversal attacks or DoS attacks. http://www.owasp.org pipedinputstream 2 This command are generally used to read data into ones application. They may be potential entry points into application. The entry points may be from an external source and must be inverstigated. Can be also used in path traversal attacks or DoS attacks. http://www.owasp.org objectstream 2 This command are generally used to read data into ones application. They may be potential entry points into application. The entry points may be from an external source and must be inverstigated. Can be also used in path traversal attacks or DoS attacks. http://www.owas.org strcpy 2 Watch out legacy methods calls. http://www.owasp.org printf 2 Watch out legacy methods calls. http://www.owasp.org deny 2 The .NET Framework relies on .config files to define configuration settings. The .config files are text-based XML files. Many .config files can, and typically do, exist on a single system. Web applications refer to a web.config file located in the application's root directory. For ASP.NET applications, web.config information about most aspects of the application's operation. http://www.owasp.org credentials 2 The .NET Framework relies on .config files to define configuration settings. The .config files are text-based XML files. Many .config files can, and typically do, exist on a single system. Web applications refer to a web.config file located in the application's root directory. For ASP.NET applications, web.config information about most aspects of the application's operation. http://www.owasp.org identity impersonate 2 The .NET Framework relies on .config files to define configuration settings. The .config files are text-based XML files. Many .config files can, and typically do, exist on a single system. Web applications refer to a web.config file located in the application's root directory. For ASP.NET applications, web.config information about most aspects of the application's operation. http://www.owasp.org timeout 2 The .NET Framework relies on .config files to define configuration settings. The .config files are text-based XML files. Many .config files can, and typically do, exist on a single system. Web applications refer to a web.config file located in the application's root directory. For ASP.NET applications, web.config information about most aspects of the application's operation. http://www.owasp.org Application_OnAuthenticateRequest 2 Each application has it's own global.asax if one is required. Global.asax sets the event code and values forn an application using scripts. One must ensure that application variables do not contains sensitive informations, as they are accessible to the whole application and to all users within it. http://www.owasp.org Application_OnAuthorizeRequest 2 Each application has it's own global.asax if one is required. Global.asax sets the event code and values forn an application using scripts. One must ensure that application variables do not contains sensitive informations, as they are accessible to the whole application and to all users within it. http://www.owasp.org Session_OnStart 2 Each application has it's own global.asax if one is required. Global.asax sets the event code and values forn an application using scripts. One must ensure that application variables do not contains sensitive informations, as they are accessible to the whole application and to all users within it. http://www.owasp.org Session_OnEnd 2 Each application has it's own global.asax if one is required. Global.asax sets the event code and values forn an application using scripts. One must ensure that application variables do not contains sensitive informations, as they are accessible to the whole application and to all users within it. http://www.owasp.org log4net 2 Logging can be a source of information leakage. It is important to examine all calls to the logging subsystem and to determinate if any sensitive information is being logged. Commomon mistakes are logging userID in conjuction with passwords within the authentication functionality or logging database requests which may contains sensitive data. http://www.owasp.org System.Diagnostics.Debug 2 Logging can be a source of information leakage. It is important to examine all calls to the logging subsystem and to determinate if any sensitive information is being logged. Commomon mistakes are logging userID in conjuction with passwords within the authentication functionality or logging database requests which may contains sensitive data. http://www.owasp.org System.Diagnostics.Trace 2 Logging can be a source of information leakage. It is important to examine all calls to the logging subsystem and to determinate if any sensitive information is being logged. Commomon mistakes are logging userID in conjuction with passwords within the authentication functionality or logging database requests which may contains sensitive data. http://www.owasp.org Thread 2 Locating code that contains multithreaded functions. Concurrency issuses can result in race conditions which may resutl in security vulnerabilities. The Treat keyword is where new threats object are created. Code that uses static global variables which hold sensitive security informations may cause session issues. Code that uses static constructors may also cause issues between threads. Not synchronizing the Dispose method may cause issues if a number of threats call Dispose at the same time, this may cause resource release issues. http://www.owasp.org Dispose 2 Locating code that contains multithreaded functions. Concurrency issuses can result in race conditions which may resutl in security vulnerabilities. The Treat keyword is where new threats object are created. Code that uses static global variables which hold sensitive security informations may cause session issues. Code that uses static constructors may also cause issues between threads. Not synchronizing the Dispose method may cause issues if a number of threats call Dispose at the same time, this may cause resource release issues. http://www.owasp.org Public 2 Public and Sealed relate to the design at class level. Classes which are not intended to be derived from should be sealed. Make sure all class fields are public for a reason. Don't expose anything you do not need to. http://www.owasp.org Sealed 2 Public and Sealed relate to the design at class level. Classes which are not intended to be derived from should be sealed. Make sure all class fields are public for a reason. Don't expose anything you do not need to. http://www.owasp.org Serializable 2 Sorry. There is not any description for this item http://www.owasp.org AllowPartiallyTrustedCallersAttribute 2 Sorry. There is not any description for this item http://www.owasp.org GetObjectData 2 Sorry. There is not any description for this item http://www.owasp.org Strongk_nameIdentityPermission 2 Sorry. There is not any description for this item http://www.owasp.org Strongk_nameIdentity 2 Sorry. There is not any description for this item http://www.owasp.org catch{ 2 Code may be generated dynamically at runtime. Code that is generated dynamically as a function of external input may give rise to issues. If your code contains sensitive data does it need to be serialized? http://www.owasp.org Finally 2 Code may be generated dynamically at runtime. Code that is generated dynamically as a function of external input may give rise to issues. If your code contains sensitive data does it need to be serialized? http://www.owasp.org trace enabled 2 Code may be generated dynamically at runtime. Code that is generated dynamically as a function of external input may give rise to issues. If your code contains sensitive data does it need to be serialized? http://www.owasp.org customErrors mode 2 Code may be generated dynamically at runtime. Code that is generated dynamically as a function of external input may give rise to issues. If your code contains sensitive data does it need to be serialized? http://www.owasp.org xor 2 If cryptography is used then is a strong enough cipher used i.e. AES or 3DES. What size key is used, the larger the better. Where is hashing performed. Are password that are being persisted hashed, they should be. How are random numbers generated? is the PRNG "random enough"? http://www.owasp.org DES 2 If cryptography is used then is a strong enough cipher used i.e. AES or 3DES. What size key is used, the larger the better. Where is hashing performed. Are password that are being persisted hashed, they should be. How are random numbers generated? is the PRNG "random enough"? http://www.owasp.org RNGCryptoServiceProvider 2 If cryptography is used then is a strong enough cipher used i.e. AES or 3DES. What size key is used, the larger the better. Where is hashing performed. Are password that are being persisted hashed, they should be. How are random numbers generated? is the PRNG "random enough"? http://www.owasp.org SHA 2 If cryptography is used then is a strong enough cipher used i.e. AES or 3DES. What size key is used, the larger the better. Where is hashing performed. Are password that are being persisted hashed, they should be. How are random numbers generated? is the PRNG "random enough"? http://www.owasp.org MD5 2 If cryptography is used then is a strong enough cipher used i.e. AES or 3DES. What size key is used, the larger the better. Where is hashing performed. Are password that are being persisted hashed, they should be. How are random numbers generated? is the PRNG "random enough"? http://www.owasp.org base64 2 If cryptography is used then is a strong enough cipher used i.e. AES or 3DES. What size key is used, the larger the better. Where is hashing performed. Are password that are being persisted hashed, they should be. How are random numbers generated? is the PRNG "random enough"? http://www.owasp.org .RequestMinimum 2 Bypassing the code access security permission? Not a good idea. This keyword is a part of a list of potentially dangerous permissions such as calling unmanaged code, outside the CLR. http://www.owasp.org .RequestOptional 2 Bypassing the code access security permission? Not a good idea. This keyword is a part of a list of potentially dangerous permissions such as calling unmanaged code, outside the CLR. http://www.owasp.org Assert 2 Bypassing the code access security permission? Not a good idea. This keyword is a part of a list of potentially dangerous permissions such as calling unmanaged code, outside the CLR. http://www.owasp.org Debug.Assert 2 Bypassing the code access security permission? Not a good idea. This keyword is a part of a list of potentially dangerous permissions such as calling unmanaged code, outside the CLR. http://www.owasp.org CodeAccessPermission 2 Bypassing the code access security permission? Not a good idea. This keyword is a part of a list of potentially dangerous permissions such as calling unmanaged code, outside the CLR. http://www.owasp.org SecurityPermission.ControlEvidence 2 Bypassing the code access security permission? Not a good idea. This keyword is a part of a list of potentially dangerous permissions such as calling unmanaged code, outside the CLR. http://www.owasp.org SecurityPermission.SerializationFormatter 2 Bypassing the code access security permission? Not a good idea. This keyword is a part of a list of potentially dangerous permissions such as calling unmanaged code, outside the CLR. http://www.owasp.org SecurityPermission.ControlPrincipal 2 Bypassing the code access security permission? Not a good idea. This keyword is a part of a list of potentially dangerous permissions such as calling unmanaged code, outside the CLR. http://www.owasp.org SecurityPermission.ControlDomainPolicy 2 Bypassing the code access security permission? Not a good idea. This keyword is a part of a list of potentially dangerous permissions such as calling unmanaged code, outside the CLR. http://www.owasp.org SecurityPermission.ControlPolicy 2 Bypassing the code access security permission? Not a good idea. This keyword is a part of a list of potentially dangerous permissions such as calling unmanaged code, outside the CLR. http://www.owasp.org Java.io 2 This command are generally used to read data into ones application. They may be potential entry points into application. The entry points may be from an external source and must be inverstigated. Can be also used in path traversal attacks or DoS attacks. http://www.owasp.org FileInputStream 2 This command are generally used to read data into ones application. They may be potential entry points into application. The entry points may be from an external source and must be inverstigated. Can be also used in path traversal attacks or DoS attacks. http://www.owasp.org FilterInputStream 2 This command are generally used to read data into ones application. They may be potential entry points into application. The entry points may be from an external source and must be inverstigated. Can be also used in path traversal attacks or DoS attacks. http://www.owasp.org SequenceInputStream 2 This command are generally used to read data into ones application. They may be potential entry points into application. The entry points may be from an external source and must be inverstigated. Can be also used in path traversal attacks or DoS attacks. http://www.owasp.org StringBufferInputStream 2 This command are generally used to read data into ones application. They may be potential entry points into application. The entry points may be from an external source and must be inverstigated. Can be also used in path traversal attacks or DoS attacks. http://www.owasp.org BufferedReader 2 This command are generally used to read data into ones application. They may be potential entry points into application. The entry points may be from an external source and must be inverstigated. Can be also used in path traversal attacks or DoS attacks. http://www.owasp.org ByteArrayInputStream 2 This command are generally used to read data into ones application. They may be potential entry points into application. The entry points may be from an external source and must be inverstigated. Can be also used in path traversal attacks or DoS attacks. http://www.owasp.org CharArrayReader 2 This command are generally used to read data into ones application. They may be potential entry points into application. The entry points may be from an external source and must be inverstigated. Can be also used in path traversal attacks or DoS attacks. http://www.owasp.org StreamTokenizer 2 This command are generally used to read data into ones application. They may be potential entry points into application. The entry points may be from an external source and must be inverstigated. Can be also used in path traversal attacks or DoS attacks. http://www.owasp.org getResourceAsStream 2 This command are generally used to read data into ones application. They may be potential entry points into application. The entry points may be from an external source and must be inverstigated. Can be also used in path traversal attacks or DoS attacks. http://www.owasp.org ConfigurationSettings 2 The .NET Framework relies on .config files to define configuration settings. The .config files are text-based XML files. Many .config files can, and typically do, exist on a single system. Web applications refer to a web.config file located in the application's root directory. For ASP.NET applications, web.config information about most aspects of the application's operation. http://www.owasp.org authentication mode 2 The .NET Framework relies on .config files to define configuration settings. The .config files are text-based XML files. Many .config files can, and typically do, exist on a single system. Web applications refer to a web.config file located in the application's root directory. For ASP.NET applications, web.config information about most aspects of the application's operation. http://www.owasp.org allow 2 The .NET Framework relies on .config files to define configuration settings. The .config files are text-based XML files. Many .config files can, and typically do, exist on a single system. Web applications refer to a web.config file located in the application's root directory. For ASP.NET applications, web.config information about most aspects of the application's operation. http://www.owasp.org getParameterValues 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org getParameter 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org getParameterMap 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org getScheme 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org getProtocol 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org getContentType 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org getServerk_name 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org getRemoteAddr 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org getRemoteHost 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org getRealPath 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org getLocalk_name 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org getAttribute 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org getAttributek_names 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org getLocalAddr 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org getAuthType 2 Sorry. There is not any description for this item http://www.owasp.org getRemoteUser 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org getCookies 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org isSecure 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org HttpServletRequest 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org getQueryString 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org getHeader 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org getPrincipal 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org isUserInRole 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org ### Castor 2 If we can identify major architectural components within that application (right away) it can help narKeyPointer our search, and we can then look for known vulnerabilities in those components and frameworks. http://www.owasp.org org.exolab.castor 2 If we can identify major architectural components within that application (right away) it can help narKeyPointer our search, and we can then look for known vulnerabilities in those components and frameworks. http://www.owasp.org ### JAXB 2 If we can identify major architectural components within that application (right away) it can help narKeyPointer our search, and we can then look for known vulnerabilities in those components and frameworks. http://www.owasp.org javax.xml 2 If we can identify major architectural components within that application (right away) it can help narKeyPointer our search, and we can then look for known vulnerabilities in those components and frameworks. http://www.owasp.org ### JMS 2 If we can identify major architectural components within that application (right away) it can help narKeyPointer our search, and we can then look for known vulnerabilities in those components and frameworks. http://www.owasp.org JMS 2 If we can identify major architectural components within that application (right away) it can help narKeyPointer our search, and we can then look for known vulnerabilities in those components and frameworks. http://www.owasp.org Hack 2 Developers say the darnedest thing in their source code. Look for the following keywords as pointers to possible software vulnerabilities.. ahhh those developers! http://www.owasp.org getRequestedSessionId 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org getValue 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org getComment 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org getDomain 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org getPath 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org getk_name 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org update 2 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org setHeader 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org addHeader 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org getWriter 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org getOutputStream 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org executequery 2 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org ExecuteReader 2 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org java.io.PrintWriter.print 2 This command are generally used to read data into ones application. They may be potential entry points into application. The entry points may be from an external source and must be inverstigated. Can be also used in path traversal attacks or DoS attacks. http://www.owasp.org jdbc 2 Sorry. There is not any description for this item http://www.owasp.org select 2 Sorry. There is not any description for this item http://www.owasp.org insert 2 Sorry. There is not any description for this item http://www.owasp.org execute 2 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org java.sql.ResultSet.getString 2 Sorry. There is not any description for this item http://www.owasp.org java.sql.ResultSet.getObject 2 Sorry. There is not any description for this item http://www.owasp.org innerHtml 2 Here we are looking for responses to the client. Responses which go unvalidated or which echo external input without data validation are key areas to examine. Many client side attacks results from poor response validation. XSS relies on this somewhat. http://www.owasp.org innertext 2 Here we are looking for responses to the client. Responses which go unvalidated or which echo external input without data validation are key areas to examine. Many client side attacks results from poor response validation. XSS relies on this somewhat. http://www.owasp.org java.sql.Statement.execute 2 Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determinate if the application is vulnerable to SQL Injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter or OdbcParameter(System.Data.SqlClient). These are type and treats parameter as the literal value and not the executable code in the database. http://www.owasp.org java.sql.Statement.addBatch 2 Sorry. There is not any description for this item http://www.owasp.org java.sql.Connection.prepareStatement 2 Sorry. There is not any description for this item http://www.owasp.org java.io.FileReader 2 This command are generally used to read data into ones application. They may be potential entry points into application. The entry points may be from an external source and must be inverstigated. Can be also used in path traversal attacks or DoS attacks. http://www.owasp.org java.io.FileWriter 2 This command are generally used to read data into ones application. They may be potential entry points into application. The entry points may be from an external source and must be inverstigated. Can be also used in path traversal attacks or DoS attacks. http://www.owasp.org java.io.RandomAccessFile 2 This command are generally used to read data into ones application. They may be potential entry points into application. The entry points may be from an external source and must be inverstigated. Can be also used in path traversal attacks or DoS attacks. http://www.owasp.org java.io.File 2 This command are generally used to read data into ones application. They may be potential entry points into application. The entry points may be from an external source and must be inverstigated. Can be also used in path traversal attacks or DoS attacks. http://www.owasp.org java.io.FileOutputStream 2 This command are generally used to read data into ones application. They may be potential entry points into application. The entry points may be from an external source and must be inverstigated. Can be also used in path traversal attacks or DoS attacks. http://www.owasp.org getParameterk_names 2 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org invalidate 2 Always be scared of the session management. Look at each session object within the application and ensure the level of security meets the requirements. http://www.owasp.org getId 2 Always be scared of the session management. Look at each session object within the application and ensure the level of security meets the requirements. http://www.owasp.org java.lang.Runtime.exec 2 This k_name may be vulnerable to command injection attacks or OS injection attacks. Java linking to the native OS can cause serious issues and potentially give rise to total server compromise. http://www.owasp.org java.io.PrintStream.write 2 We may come across some information leakage by examing code below contained in ones application. http://www.owasp.org log4j 2 We may come across some information leakage by examing code below contained in ones application. http://www.owasp.org jLo 2 We may come across some information leakage by examing code below contained in ones application. http://www.owasp.org Lumberjack 2 We may come across some information leakage by examing code below contained in ones application. http://www.owasp.org MonoLog 2 We may come across some information leakage by examing code below contained in ones application. http://www.owasp.org qflog 2 We may come across some information leakage by examing code below contained in ones application. http://www.owasp.org just4log 2 We may come across some information leakage by examing code below contained in ones application. http://www.owasp.org log4Ant 2 We may come across some information leakage by examing code below contained in ones application. http://www.owasp.org JDLabAgent 2 We may come across some information leakage by examing code below contained in ones application. http://www.owasp.org ### Ajax 2 If we can identify major architectural components within that application (right away) it can help narKeyPointer our search, and we can then look for known vulnerabilities in those components and frameworks. http://www.owasp.org XMLHTTP 2 If we can identify major architectural components within that application (right away) it can help narKeyPointer our search, and we can then look for known vulnerabilities in those components and frameworks. http://www.owasp.org ### Struts 2 If we can identify major architectural components within that application (right away) it can help narKeyPointer our search, and we can then look for known vulnerabilities in those components and frameworks. http://www.owasp.org org.apache.struts 2 If we can identify major architectural components within that application (right away) it can help narKeyPointer our search, and we can then look for known vulnerabilities in those components and frameworks. http://www.owasp.org ### Spring 2 If we can identify major architectural components within that application (right away) it can help narKeyPointer our search, and we can then look for known vulnerabilities in those components and frameworks. http://www.owasp.org org.springframework 2 If we can identify major architectural components within that application (right away) it can help narKeyPointer our search, and we can then look for known vulnerabilities in those components and frameworks. http://www.owasp.org ### Java Server Faces (JSF) 2 If we can identify major architectural components within that application (right away) it can help narKeyPointer our search, and we can then look for known vulnerabilities in those components and frameworks. http://www.owasp.org import javax.faces 2 If we can identify major architectural components within that application (right away) it can help narKeyPointer our search, and we can then look for known vulnerabilities in those components and frameworks. http://www.owasp.org ### Hibernate 2 If we can identify major architectural components within that application (right away) it can help narKeyPointer our search, and we can then look for known vulnerabilities in those components and frameworks. http://www.owasp.org import org.hibernate 2 Sorry. There is not any description for this item http://www.owasp.org <frameset> 2 Many of the HTML tags below can be used for client side attacks such as cross site scripting. It is important to examine the context in which these tags are used and to examine any relevant data validation associated with the display. http://www.owasp.org <embed> 2 Many of the HTML tags below can be used for client side attacks such as cross site scripting. It is important to examine the context in which these tags are used and to examine any relevant data validation associated with the display. http://www.owasp.org <frame> 2 Many of the HTML tags below can be used for client side attacks such as cross site scripting. It is important to examine the context in which these tags are used and to examine any relevant data validation associated with the display. http://www.owasp.org <html> 2 Many of the HTML tags below can be used for client side attacks such as cross site scripting. It is important to examine the context in which these tags are used and to examine any relevant data validation associated with the display. http://www.owasp.org <iframe> 2 Many of the HTML tags below can be used for client side attacks such as cross site scripting. It is important to examine the context in which these tags are used and to examine any relevant data validation associated with the display. http://www.owasp.org <img> 2 Many of the HTML tags below can be used for client side attacks such as cross site scripting. It is important to examine the context in which these tags are used and to examine any relevant data validation associated with the display. http://www.owasp.org <style> 2 Many of the HTML tags below can be used for client side attacks such as cross site scripting. It is important to examine the context in which these tags are used and to examine any relevant data validation associated with the display. http://www.owasp.org <layer> 2 Many of the HTML tags below can be used for client side attacks such as cross site scripting. It is important to examine the context in which these tags are used and to examine any relevant data validation associated with the display. http://www.owasp.org Kludge 2 Developers say the darnedest thing in their source code. Look for the following keywords as pointers to possible software vulnerabilities.. ahhh those developers! http://www.owasp.org Bypass 2 Developers say the darnedest thing in their source code. Look for the following keywords as pointers to possible software vulnerabilities.. ahhh those developers! http://www.owasp.org Steal 2 Developers say the darnedest thing in their source code. Look for the following keywords as pointers to possible software vulnerabilities.. ahhh those developers! http://www.owasp.org Stolen 2 Developers say the darnedest thing in their source code. Look for the following keywords as pointers to possible software vulnerabilities.. ahhh those developers! http://www.owasp.org Divert 2 Developers say the darnedest thing in their source code. Look for the following keywords as pointers to possible software vulnerabilities.. ahhh those developers! http://www.owasp.org Broke 2 Developers say the darnedest thing in their source code. Look for the following keywords as pointers to possible software vulnerabilities.. ahhh those developers! http://www.owasp.org Trick 2 Developers say the darnedest thing in their source code. Look for the following keywords as pointers to possible software vulnerabilities.. ahhh those developers! http://www.owasp.org Fix 2 Developers say the darnedest thing in their source code. Look for the following keywords as pointers to possible software vulnerabilities.. ahhh those developers! http://www.owasp.org ToDo 2 Developers say the darnedest thing in their source code. Look for the following keywords as pointers to possible software vulnerabilities.. ahhh those developers! http://www.owasp.org document.write 2 Look for Ajax usage, and possible Javascript issues. http://www.owasp.org eval( 2 Look for Ajax usage, and possible Javascript issues. http://www.owasp.org document.cookie 2 Cookie manipulation can be key to various application security exploits such as session hijacking/fixation and parameter manipulation. One should examine any code relating to cookie functionalty as this would have a bearing on session security. http://www.owasp.org window.location 2 Look for Ajax usage, and possible Javascript issues. http://www.owasp.org document.URL 2 Look for Ajax usage, and possible Javascript issues. http://www.owasp.org window.createRequest 2 Sorry. There is not any description for this item http://www.owasp.org getSession 2 Always be scared of the session management. Look at each session object within the application and ensure the level of security meets the requirements. http://www.owasp.org KeyManagerFactory 2 Looking for code which utilises SSL as a medium for point to point encryption. This fragment should indicate where SSL functionality has been developed. http://www.owasp.org HttpsURLConnection 2 Looking for code which utilises SSL as a medium for point to point encryption. This fragment should indicate where SSL functionality has been developed. http://www.owasp.org TrustManagerFactory 2 Looking for code which utilises SSL as a medium for point to point encryption. This fragment should indicate where SSL functionality has been developed. http://www.owasp.org SSLSocketFactory 2 Looking for code which utilises SSL as a medium for point to point encryption. This fragment should indicate where SSL functionality has been developed. http://www.owasp.org SSLContext 2 Looking for code which utilises SSL as a medium for point to point encryption. This fragment should indicate where SSL functionality has been developed. http://www.owasp.org com.sun.net.ssl 2 Looking for code which utilises SSL as a medium for point to point encryption. This fragment should indicate where SSL functionality has been developed. http://www.owasp.org java.sql.Connection.prepareCall 2 Sorry. There is not any description for this item http://www.owasp.org response.write 2 Here we are looking for responses to the client. Responses which go unvalidated or which echo external input without data validation are key areas to examine. Many client side attacks results from poor response validation. XSS relies on this somewhat. http://www.owasp.org request.TotalBytes 2 Requests from external sources are obviously a key area of a secure code review. We http://www.owasp.org request.IsSecureConnection 2 Requests from external sources are obviously a key area of a secure code review. We http://www.owasp.org request.servervariables 2 Requests from external sources are obviously a key area of a secure code review. We http://www.owasp.org <%= 2 Here we are looking for responses to the client. Responses which go unvalidated or which echo external input without data validation are key areas to examine. Many client side attacks results from poor response validation. XSS relies on this somewhat. http://www.owasp.org HttpUtility 2 Here we are looking for responses to the client. Responses which go unvalidated or which echo external input without data validation are key areas to examine. Many client side attacks results from poor response validation. XSS relies on this somewhat. http://www.owasp.org enableViewStateMac 2 It is important that many variables in machine.config can be overridden in the web.config file for a particular application. http://www.owasp.org SecureString 2 If storing sensitive data in memory recommend one uses the following. http://www.owas.org Console.WriteLine 1 Logging can be a source of information leakage. It is important to examine all calls to the logging subsystem and to determinate if any sensitive information is being logged. Commomon mistakes are logging userID in conjuction with passwords within the authentication functionality or logging database requests which may contains sensitive data. http://www.owasp.org System.Reflection 1 Sorry. There is not any description for this item http://www.owasp.org SecurityPermission.SkipVerification 1 Bypassing the code access security permission? Not a good idea. This keyword is a part of a list of potentially dangerous permissions such as calling unmanaged code, outside the CLR. http://www.owasp.org addCookie 1 This API call may be avenues for parameter, header, URL & Cookie tampering, HTTP Response Splitting and information leakage. They should be examined closely as may of such API's obtain the parameters directly from HTTP requests. http://www.owasp.org debug 1 The .NET Framework relies on .config files to define configuration settings. The .config files are text-based XML files. Many .config files can, and typically do, exist on a single system. Web applications refer to a web.config file located in the application's root directory. For ASP.NET applications, web.config information about most aspects of the application's operation. http://www.owasp.org UrlEncode 1 Many of the HTML tags below can be used for client side attacks such as cross site scripting. It is important to examine the context in which these tags are used and to examine any relevant data validation associated with the display. http://www.owasp.org SecurityPermission.UnmanagedCode 1 Bypassing the code access security permission? Not a good idea. This keyword is a part of a list of potentially dangerous permissions such as calling unmanaged code, outside the CLR. http://www.owasp.org HtmlEncode 1 Many of the HTML tags below can be used for client side attacks such as cross site scripting. It is important to examine the context in which these tags are used and to examine any relevant data validation associated with the display. http://www.owasp.org