فا

‫ اخبار

صفحات: « 1 2 3 4 5 ... » »»
Web Browser Security Revisited (Part 5)-part one
Number: IRCAR201410237
Date: 2014/10/21
Introduction
In this article, we’ll look specifically at the special features Google provides for enterprise administrators with its Chrome for Business.
Google Chrome for Business
Chrome for Business can be deployed on all three of the popular client operating systems: Windows, Linux or Mac computers. Google provides a downloadable MSI file that you can use for offline installations. You can download it from the Google web site.
The MSI can be deployed via System Center Configuration Manager (SCCM) or other automated deployment tools, or can be scripted with the command:
Msiexec /q /I GoogleChrome.msi
Note that on corporate computers (in a domain), even if Chrome has already been installed by the user, the browser will still adhere to the policies.
Chrome for Business on Windows
On a Windows Server-based network, you can use Group Policy to control Chrome settings such as setting a common home page for all users, turning off auto updates, forcing accessibility settings, enabling firewall traversal for remote access, controlling cookies, plug-ins and JavaScript settings, blocking images, and much more.
Security-related Group Policy Settings
Some of the most important Group Policy settings, for those concerned with security, include the following:
  • RemoteAccessHostFirewallTraversal is a REG_DWORD value by which you can allow remote clients to discover and connect to the computer when separated by a firewall. If you want the computer to allow connections only from clients within the local area network, you need to disable this policy. It is enabled by default.
  • RemoteAccessHostDomain is a REG_SZ value by which you can configure a required host domain name for remote access hosts. Enabling the setting restricts sharing of hosts to accounts that are registered in that domain and users cannot change the host domain name. By default, any account can be used to share hosts.
  • RemoteAccessHostRequireTwoFactor is a REG_DWORD value by which you can require that users provide a two-factor authentication code to access a remote host computer. By default, a user-defined Personal Identification Number (PIN) is used to authenticate to remote access hosts.
  • RemoteAccessHostRequireCurtain is a REG_DWORD value by which you can disable the host computer’s physical input/output devices during remote connections. By default, local and remote users can both interact with a shared host.
There are also a number of settings that allow you to specify how Chrome will handle different types of content. These include:
  • DefaultCookiesSetting
  • DefaultImagesSetting
  • DefaultPluginsSetting
  • DefaultPopupsSetting
  • DefaultGeolocationSetting
  • DefaultJavaScriptSetting
The last one is especially important since allowing the running of JavaScript can pose security risks. Chrome’s sandboxing feature will ameliorate this but you can prevent web sites from running JavaScript by setting the value of this policy to “2.” By default, JavaScript is allowed and users can change the setting in the GUI.
In addition to default settings, there are policies by which you can fine-tune settings. For example, using the CookiesAllowedForUrls and CookiesBlockedForUrls policies, you can define specific URLs for sites that you want to allow to set cookies, or those that you want to block from setting cookies. You can do the same for display of images by web sites, allowing JavaScript for specific sites, and so forth.
The ExtensionInstallBlacklist policy can be used to specify Chrome browser extensions that users will not be allowed to install, and if extensions on the list are already installed on a computer, they will be removed. You can go even further and use a value of “*” to blacklist all extensions, with the exceptions of those that you specifically whitelist. As you might have surmised, there is also an ExtensionInstallWhitelist policy where you can specify allowed extensions. You can even force specific extensions to be installed with the ExtensionInstallForcelist policy.
Another helpful set of policies makes it possible for admins to create supervised (managed) users. This ability is enabled by default on consumer devices but disabled on enterprise devices (however, you can enable it using the SupervisedUsersEnabled policy).
You can also control whether or not users can show stored passwords in plain text. This is an option in the Chrome browser that has stirred up a bit of controversy. When a user goes to Settings | Show Advanced Settings | Passwords and forms | Manage saved passwords, Chrome lists the saved passwords and the user can click a Show button to display a particular password in plain text. This can obviously present a security risk since an unauthorized user could sit down at an unlocked computer and view the passwords. The Password Manager Group Policy settings can be used to prevent users from displaying the passwords, with the PasswordManagerAllowShowPasswords policy, or even prevent them from saving passwords entirely, with the PasswordManagerEnabled policy.
You can set mandatory or recommended policies. Mandatory preferences go in the HKEY_LOCAL_MACHINE registry key and recommended preferences go in the HKEY_LOCAL_USER registry key.
Resource:
29 مهر 1393 برچسب‌ها: مقالات
SQL Server Security- Last Section- SQL Server Express Security
ID: IRCAR201410236
Date: 2014-10-20
  1. Introduction
SQL Server has many features that support creating secure database applications. Common security considerations, such as data theft or vandalism, apply regardless of the version of SQL Server you are using. Data integrity should also be considered as a security issue. If data is not protected, it is possible that it could become worthless if ad hoc data manipulation is permitted and the data is inadvertently or maliciously modified with incorrect values or deleted entirely. In addition, there are often legal requirements that must be adhered to, such as the correct storage of confidential information. Storing some kinds of personal data is proscribed entirely, depending on the laws that apply in a particular jurisdiction.
Each version of SQL Server has different security features, as does each version of Windows, with later versions having enhanced functionality over earlier ones. It is important to understand that security features alone cannot guarantee a secure database application. Each database application is unique in its requirements, execution environment, deployment model, physical location, and user population. Some applications that are local in scope may need only minimal security whereas other local applications or applications deployed over the Internet may require stringent security measures and ongoing monitoring and evaluation.
The security requirements of a SQL Server database application should be considered at design time, not as an afterthought. Evaluating threats early in the development cycle gives you the opportunity to mitigate potential damage wherever a vulnerability is detected.
Even if the initial design of an application is sound, new threats may emerge as the system evolves. By creating multiple lines of defense around your database, you can minimize the damage inflicted by a security breach. Your first line of defense is to reduce the attack surface area by never to granting more permissions than are absolutely necessary.
The topics in this section briefly describe the security features in SQL Server that are relevant for developers, with links to relevant topics in SQL Server Books Online and other resources that provide more detailed coverage.
  1. SQL Server Express Security
Microsoft SQL Server Express Edition (SQL Server Express) is based on Microsoft SQL Server, and supports most of the features of the database engine. It is designed so that nonessential features and network connectivity are off by default. This reduces the surface area available for attack by a malicious user.
SQL Server Express is usually installed as a named instance. The default name of the instance is SQLExpress. A named instance is identified by the network name of the computer plus the instance name that you specify during installation.
2.1. Network Access

For security reasons, networking protocols are disabled by default in SQL Server Express. This prevents attacks from outside users that might compromise the computer that hosts the instance of SQL Server Express. You must explicitly enable network connectivity and start the SQL Server Browser service to connect to a SQL Server Express instance from another computer.
Once network connectivity is enabled, a SQL Server Express instance has the same security requirements as the other editions of SQL Server.

A user instance is a separate instance of the SQL Server Express database engine that is generated by a parent instance of SQL Server Express. The primary goal of a user instance is to allow users who are running Windows under a least-privilege user account to have system administrator (sysadmin) privileges on the SQL Server Express instance on their local computer. User instances are not intended for users who are system administrators on their own computers.
A user instance is generated from a primary instance of SQL Server or SQL Server Express on behalf of a user. It runs as a user process under the Windows security context of the user, not as a service. SQL Server logins are disallowed; only Windows logins are supported. This prevents software executing on a user instance from making system-wide changes that the user would not have permissions to make. A user instance is also known as a child or client instance, and is sometimes referred to by using the RANU acronym ("run as normal user").
Each user instance is isolated from its parent instance and from other user instances running on the same computer. Databases installed on user instances are opened in single-user mode only; multiple users cannot connect to them. Replication, distributed queries and remote connections are disabled for user instances. When connected to a user instance, users do not have any special privileges on the parent SQL Server Express instance.

References:
28 مهر 1393 برچسب‌ها: مقالات
IDS08-J. Sanitize untrusted data passed to a regex
ID: IRCAR201410235
Date: 2014/10/17
Regular expressions are widely used to match strings of text. For example, the POSIX grep utility supports regular expressions for finding patterns in the specified text. For introductory information on regular expressions, see the Java Tutorials [Tutorials 08]. The java.util.regex package provides the Pattern class that encapsulates a compiled representation of a regular expression and the Matcher class, which is an engine that uses a Pattern to perform matching operations on a CharSequence.
Java's powerful regular expression (regex) facilities must be protected from misuse. An attacker may supply a malicious input that modifies the original regular expression in such a way that the regex fails to comply with the program's specification. This attack vector, called a regex injection, might affect control flow, cause information leaks, or result in denial-of-service (DoS) vulnerabilities.
Certain constructs and properties of Java regular expressions are susceptible to exploitation:
  • Matching flags: Untrusted inputs may override matching options that may or may not have been passed to the Pattern.compile() method.
  • Greediness: An untrusted input may attempt to inject a regex that changes the original regex to match as much of the string as possible, exposing sensitive information.
  • Grouping: The programmer can enclose parts of a regular expression in parentheses to perform some common action on the group. An attacker may be able to change the groupings by supplying untrusted input.
Untrusted input should be sanitized before use to prevent regex injection. When the user must specify a regex as input, care must be taken to ensure that the original regex cannot be modified without restriction. Whitelisting characters (such as letters and digits) before delivering the user-supplied string to the regex parser is a good input sanitization strategy. A programmer must provide only a very limited subset of regular expression functionality to the user to minimize any chance of misuse.
Regex Injection Example
Suppose a system log file contains messages output by various system processes. Some processes produce public messages and some processes produce sensitive messages marked "private." Here is an example log file:
A user wishes to search the log file for interesting messages but must be prevented from seeing the private messages. A program might accomplish this by permitting the user to provide search text that becomes part of the following regex:
However, if an attacker can substitute any string for <SEARCHTEXT>, he can perform a regex injection with the following text:
When injected into the regex, the regex becomes:
This regex will match any line in the log file, including the private ones.
Noncompliant Code Example
This noncompliant code example periodically loads the log file into memory and allows clients to obtain keyword search suggestions by passing the keyword as an argument to suggestSearches().
This code permits a trusted user to search for public log messages such as "error." However, it also allows a malicious attacker to perform the regex injection previously described.
Compliant Solution (Whitelisting)
This compliant solution filters out nonalphanumeric characters (except space and single quote) from the search string, which prevents regex injection.
This solution also limits the set of valid search terms. For instance, a user may no longer search for "name =" because the = character would be sanitized out of the regex.
Compliant Solution
Another method of mitigating this vulnerability is to filter out the sensitive information prior to matching. Such a solution would require the filtering to be done every time the log file is periodically refreshed, incurring extra complexity and a performance penalty. Sensitive information may still be exposed if the log format changes but the class is not also refactored to accommodate these changes.
Risk Assessment
Failing to sanitize untrusted data included as part of a regular expression can result in the disclosure of sensitive information.
Reference:
27 مهر 1393 برچسب‌ها: مقالات
Mobile Device Management Features

Number: IRCAR201409234

Date: 2014-09-20

Sales of smartphones and tablet devices have exploded over the last five years or so. Increasingly these mobile devices are being used in the workplace.

But mobile device usage introduces security risks. The devices can be used to access corporate networks and store sensitive corporate data, putting data at risk when the user walks out of the corporate front door with the device in their pocket. What if the device is left in the back of a cab, or the user moves to a new job while using the same device?

Most mobile devices can be configured so a password is required to unlock them, but popular platforms such as Android and Apple's iOS were not built with enterprise security in mind. What businesses need for security purposes - and what regulatory compliance may require - is a way to ensure that all devices are configured that way, and in a way that users cannot override. Security goes way beyond passwords. There are multiple settings that need to be configured - and stay configured - on every mobile device to provide a baseline security level.

A mobile device management (MDM) system provides a solution to this problem. Once a mobile device is enrolled on the system, the device can be configured automatically with a standard set of security settings. It can then either prevent the user from changing these settings, or remotely wipe the phone and remove access to corporate networks if it detects that the settings are changed by the user.

Mobile device management (MDM) can help enterprises minimize security risks associated with BYOD. Here is what you need to know if you plan to use an MDM system.

Mobile Device Management Features

A mobile device management system is usually limited to configuring settings that any given mobile operating system makes available, and for that reason most MDMs provide broadly the same set of security features on each mobile device platform. These may vary on a device by device basis, but usually include:

· Enforcement of device PIN/password usage. Ensuring that the device can only be accessed fter entering a (usually) four-digit PIN or, preferably, a password or phrase that is not easily guessable. These can be reset from the MDM if forgotten.

· Remote device lock/wipe. Giving administrators the ability to lock or delete the data - either all data or just corporate data - from a device that is reported lost or stolen. Many mobile device management systems also include geolocation to help employees find lost devices and reduce costs related to lost devices.

· Data encryption. Activating on-device data encryption on platforms such as iOS that have it built in, or adding this functionality to platforms such as Android that might not.

· Jailbreak/root detection. Jailbreaking or rooting a mobile device frees it from many OS-level security restrictions, and may also enable users to bypass security controls imposed by an MDM. For that reason, it is vital that an MDM can detect when a device has been jailbroken or rooted.

In addition to configuring these sorts of security settings, most mobile device management platforms also allow administrators to see the internal state of any mobile device remotely, including the configuration settings and installed applications. Operating system and application updates can be pushed to devices to minimize security or reliability issues, and policies based on Active Directory (or other directory) groups can often be imposed, limiting devices belonging to users in different groups so they can only access to appropriate corporate resources.

Most MDMs also enable a huge variety of further group policies and restrictions to be imposed on mobile devices. These may include preventing the device's camera from being used (or preventing it from being used in certain geographic locations such as the corporate offices), prohibiting the installation of applications which appear on a blacklist, blocking in-app purchases, or preventing any apps from being installed unless they are downloaded from an enterprise app store controlled by the MDM.

Reference:

http://www.esecurityplanet.com/

7 مهر 1393 برچسب‌ها: مقالات
SQL Server Security- 11th Section- Enabling Cross-Database Access

Number: IRCAR201409233

Date: 2014-09-20

  1. Introduction

SQL Server has many features that support creating secure database applications. Common security considerations, such as data theft or vandalism, apply regardless of the version of SQL Server you are using. Data integrity should also be considered as a security issue. If data is not protected, it is possible that it could become worthless if ad hoc data manipulation is permitted and the data is inadvertently or maliciously modified with incorrect values or deleted entirely. In addition, there are often legal requirements that must be adhered to, such as the correct storage of confidential information. Storing some kinds of personal data is proscribed entirely, depending on the laws that apply in a particular jurisdiction.

Each version of SQL Server has different security features, as does each version of Windows, with later versions having enhanced functionality over earlier ones. It is important to understand that security features alone cannot guarantee a secure database application. Each database application is unique in its requirements, execution environment, deployment model, physical location, and user population. Some applications that are local in scope may need only minimal security whereas other local applications or applications deployed over the Internet may require stringent security measures and ongoing monitoring and evaluation.

The security requirements of a SQL Server database application should be considered at design time, not as an afterthought. Evaluating threats early in the development cycle gives you the opportunity to mitigate potential damage wherever a vulnerability is detected.

Even if the initial design of an application is sound, new threats may emerge as the system evolves. By creating multiple lines of defense around your database, you can minimize the damage inflicted by a security breach. Your first line of defense is to reduce the attack surface area by never to granting more permissions than are absolutely necessary.

The topics in this section briefly describe the security features in SQL Server that are relevant for developers, with links to relevant topics in SQL Server Books Online and other resources that provide more detailed coverage.

  1. Enabling Cross-Database Access in SQL Server

Cross-database ownership chaining occurs when a procedure in one database depends on objects in another database. A cross-database ownership chain works in the same way as ownership chaining within a single database, except that an unbroken ownership chain requires that all the object owners are mapped to the same login account. If the source object in the source database and the target objects in the target databases are owned by the same login account, SQL Server does not check permissions on the target objects.

2.1. Off By Default


Ownership chaining across databases is turned off by default. Microsoft recommends that you disable cross-database ownership chaining because it exposes you to the following security risks:

  • Database owners and members of the db_ddladmin or the db_owners database roles can create objects that are owned by other users. These objects can potentially target objects in other databases. This means that if you enable cross-database ownership chaining, you must fully trust these users with data in all databases.
  • Users with CREATE DATABASE permission can create new databases and attach existing databases. If cross-database ownership chaining is enabled, these users can access objects in other databases that they might not have privileges in from the newly created or attached databases that they create.

2.2. Enabling Cross-database Ownership Chaining


Cross-database ownership chaining should only be enabled in environments where you can fully trust highly-privileged users. It can be configured during setup for all databases, or selectively for specific databases using the Transact-SQL commands sp_configure and ALTER DATABASE.

To selectively configure cross-database ownership chaining, use sp_configure to turn it off for the server. Then use the ALTER DATABASE command with SET DB_CHAINING ON to configure cross-database ownership chaining for only the databases that require it.

The following sample turns on cross-database ownership chaining for all databases:

EXECUTE sp_configure 'show advanced', 1;
RECONFIGURE;
EXECUTE sp_configure 'cross db ownership chaining', 1;
RECONFIGURE;

The following sample turns on cross-database ownership chaining for specific databases:

ALTER DATABASE Database1 SET DB_CHAINING ON;
ALTER DATABASE Database2 SET DB_CHAINING ON;

2.3. Dynamic SQL


Cross-database ownership chaining does not work in cases where dynamically created SQL statements are executed unless the same user exists in both databases. You can work around this in SQL Server by creating a stored procedure that accesses data in another database and signing the procedure with a certificate that exists in both databases. This gives users access to the database resources used by the procedure without granting them database access or permissions.


References:

http://msdn.microsoft.com/
7 مهر 1393 برچسب‌ها: مقالات
SQL Server Security- 10th Section- Granting Row-Level Permissions and Creating Application Roles
Number: IRCAR201409231
Date: 2014-09-09
1.1. Granting Row-Level Permissions in SQL Server
In some scenarios, there is a requirement to control access at a more granular level than that allowed by simply granting, revoking, or denying permissions on the data. For example, a hospital database application may store patient information in a single table. Doctors may need to be restricted to viewing information related to their own patients. Similar scenarios exist in many environments, including finance, law, government, and military applications. However, SQL Server does not have support for implementing row-level security. You must create additional columns in your tables that define row filtering mechanisms.

Row-level permissions are used for applications that store information in a single table. Each row has a column that defines a differentiating parameter, such as a user name, label or other identifier. You then create parameterized stored procedures, passing in the appropriate value. Users can see only rows that match the supplied value.
The following steps describe how to configure row-level permissions based on a user or login name.
  • Create the table, adding an additional column to store the name.
  • Create a view that has a WHERE clause based on the user name column. This will restrict the rows returned to those with the specified value. Use one of the built-in functions to specify a database user or login name. This eliminates the need to create different views for different users.
' Returns the login identification name of the user.
WHERE UserName = SUSER_SNAME()
' USER_NAME or CURRENT_USER Return the database user name.
WHERE UserName = CURRENT_USER()
  • Create stored procedures to select, insert, update, and delete data based on the view, not the base tables. The view provides a filter that restricts the rows returned or modified.
  • For stored procedures that insert data, capture the user name using the same function specified in the WHERE clause of the view and insert that value into the UserName column.
  • Deny all permissions o÷n the tables and views to the public role. Users will not be able to inherit permissions from other database roles, because the WHERE clause is based on user or login names, not on roles.
  • Grant EXECUTE on the stored procedures to database roles. Users can only access data through the stored procedures provided.
1.2. Creating Application Roles in SQL Server
Application roles provide a way to assign permissions to an application instead of a database role or user. Users can connect to the database, activate the application role, and assume the permissions granted to the application. The permissions granted to the application role are in force for the duration of the connection.

Security Note
Application roles are activated when a client application supplies an application role name and a password in the connection string. They present a security vulnerability in a two-tier application because the password must be stored on the client computer. In a three-tier application, you can store the password so that it cannot be accessed by users of the application.

Application roles have the following features:
  • Unlike database roles, application roles contain no members.
  • Application roles are activated when an application supplies the application role name and a password to the sp_setapprole system stored procedure.
  • The password must be stored on the client computer and supplied at run time; an application role cannot be activated from inside of SQL Server.
  • The password is not encrypted. The parameter password is stored as a one-way hash.
  • Once activated, permissions acquired through the application role remain in effect for the duration of the connection.
  • The application role inherits permissions granted to the public role.
  • If a member of the sysadmin fixed server role activates an application role, the security context switches to that of the application role for the duration of the connection.
  • If you create a guest account in a database that has an application role, you do not need to create a database user account for the application role or for any of the logins that invoke it. Application roles can directly access another database only if a guest account exists in the second database
  • Built-in functions that return login names, such as SYSTEM_USER, return the name of the login that invoked the application role. Built-in functions that return database user names return the name of the application role.

Application roles should be granted only required permissions in case the password is compromised. Permissions to the public role should be revoked in any database using an application role. Disable the guest account in any database you do not want callers of the application role to have access to.

The execution context can be switched back to the original caller after activating an application role, removing the need to disable connection pooling. The sp_setapprole procedure has a new option that creates a cookie, which contains context information about the caller. You can revert the session by calling the sp_unsetapprole procedure, passing it the cookie.

Application roles depend on the security of a password, which presents a potential security vulnerability. Passwords may be exposed by being embedded in application code or saved on disk.
You may want to consider the following alternatives.
  • Use context switching with the EXECUTE AS statement with its NO REVERT and WITH COOKIE clauses. You can create a user account in a database that is not mapped to a login. You then assign permissions to this account. Using EXECUTE AS with a login-less user is more secure because it is permission-based, not password-based.
  • Sign stored procedures with certificates, granting only permission to execute the procedures.

References:
7 مهر 1393 برچسب‌ها: مقالات
Database Security: Threats and Challenges (Part 2)
Number: IRCAR201408230
Date: 2014-08-19
In the previous part of this article, we studied about some security threats to database. Other types of database security threats are described.
SECURITY THREATS TO DATABASE (Cont’d)
C. Privilege Elevation
Sometimes there are vulnerabilities in database software and attackers may take advantage of that to convert their access privileges from an ordinary user to those of an administrator, which could result in bogus accounts, transfer of funds, and misinterpretation of certain sensitive analytical information. A database rootkit is such a program or a procedure that is hidden inside the database and that provides administrator-level privileges to gain access to the data in the database. These rootkits may even turn off alerts triggered by Intrusion Prevention Systems (IPS). It is possible to install a rootkit only after compromising the underlying operating system.
D. Platform Vulnerabilities
Vulnerabilities in operating systems and additional services installed on a database server may lead to unauthorized access, data corruption, or denial of service. For example, the Blaster Worm took advantage of a Windows 2000 vulnerability to create denial of service conditions.
E. Inference
Even in secure DBMSs, it is possible for users to draw inferences from the information they obtain from the database. A user can draw inference from a database when the user can guess or conclude more sensitive information from the retrieved information from the database or additionally with some prior knowledge. An inference presents a security breach if more highly classified information can be inferred from less classified information. There are two important cases of the inference problem, which often arise in database systems.
1) Aggregation problem: occurs when a collection of data items is more sensitive i.e. classified at a higher level than the levels of individual data items. For example in an organization the profit of each branch is not sensitive but total profit of organization is at higher level of classification.
2) Data association problem: occurs whenever two values seen together are classified at a higher level than the classification of either value individually. As an example, the list containing the names of all employees and the list containing all employee salaries are unclassified, while a combined list giving employee names with their salaries is classified.
F. SQL Injection
In a SQL injection attack, an attacker typically inserts (or “injects”) unauthorized SQL statements into a vulnerable SQL data channel. Typically targeted data channels include stored procedures and Web application input parameters. These injected statements are then passed to the database where they are executed. For example in a web application the user inserts a query instead of his name. Using SQL injection, attackers may gain unrestricted access to an entire database.
G. Unpatched DBMS
In database, as the vulnerabilities are kept changing that are being exploited by attackers, database vendors release patches so that sensitive information in databases remain protected from threats. Once these patches are released they should be patched immediately. If left unpatched, hackers can reverse engineer the patch, or can often find information online on how to exploit the unpatched vulnerabilities, leaving a DBMS even more vulnerable that before the patch was released.
H. Unnecessary DBMS Features Enabled
In a DBMS there are many unneeded features which are enabled by default and which should be turned off otherwise they would be the reason for the most effective attacks on a database.
I. Misconfigurations
Unnecessary features are left on because of poor configuration at the database level. Database misconfigurations provide weak access points for hackers to bypass authentication methods and gain access to sensitive information. These flaws become the main targets for criminals to execute certain types of attacks. Default settings may not have been properly re-set, unencrypted files may be accessible to non-privileged users, and unpatched flaws may lead to unauthorized access of sensitive data.
J. Buffer Overflow
When a program or process tries to store more data in a buffer than it was intended to hold, this situation is called buffer overflow. Since buffers contains only a finite amount of data, the extra data - which has to go somewhere - can overflow into adjacent locations, corrupting or overwriting the valid data held in those locations. For example, a program is waiting for a user to enter his or her name. Rather than entering the name, the hacker would enter an executable command that exceeds the size of buffer. The command is usually something short.

References:
http://www.ijarcsse.com/docs/papers/Volume_3/5_May2013/
7 مهر 1393 برچسب‌ها: مقالات
SQL Server Security- 9th Section- Signing Stored Procedures and Customizing Permissions with Impersonation
Number: IRCAR201408229
Date: 2014-08-13
  1. Introduction
SQL Server has many features that support creating secure database applications. Common security considerations, such as data theft or vandalism, apply regardless of the version of SQL Server you are using. Data integrity should also be considered as a security issue. If data is not protected, it is possible that it could become worthless if ad hoc data manipulation is permitted and the data is inadvertently or maliciously modified with incorrect values or deleted entirely. In addition, there are often legal requirements that must be adhered to, such as the correct storage of confidential information. Storing some kinds of personal data is proscribed entirely, depending on the laws that apply in a particular jurisdiction.
Each version of SQL Server has different security features, as does each version of Windows, with later versions having enhanced functionality over earlier ones. It is important to understand that security features alone cannot guarantee a secure database application. Each database application is unique in its requirements, execution environment, deployment model, physical location, and user population. Some applications that are local in scope may need only minimal security whereas other local applications or applications deployed over the Internet may require stringent security measures and ongoing monitoring and evaluation.
The security requirements of a SQL Server database application should be considered at design time, not as an afterthought. Evaluating threats early in the development cycle gives you the opportunity to mitigate potential damage wherever a vulnerability is detected.
Even if the initial design of an application is sound, new threats may emerge as the system evolves. By creating multiple lines of defense around your database, you can minimize the damage inflicted by a security breach. Your first line of defense is to reduce the attack surface area by never to granting more permissions than are absolutely necessary.
The topics in this section briefly describe the security features in SQL Server that are relevant for developers, with links to relevant topics in SQL Server Books Online and other resources that provide more detailed coverage.
  1. Signing Stored Procedures in SQL Server
You can sign a stored procedure with a certificate or an asymmetric key. This is designed for scenarios when permissions cannot be inherited through ownership chaining or when the ownership chain is broken, such as dynamic SQL. You then create a user mapped to the certificate, granting the certificate user permissions on the objects the stored procedure needs to access.
When the stored procedure is executed, SQL Server combines the permissions of the certificate user with those of the caller. Unlike the EXECUTE AS clause, it does not change the execution context of the procedure. Built-in functions that return login and user names return the name of the caller, not the certificate user name.
A digital signature is a data digest encrypted with the private key of the signer. The private key ensures that the digital signature is unique to its bearer or owner. You can sign stored procedures, functions, or triggers.
Note
You can create a certificate in the master database to grant server-level permissions.

When you sign a stored procedure with a certificate, a data digest consisting of the encrypted hash of the stored procedure code is created using the private key. At run time, the data digest is decrypted with the public key and compared with the hash value of the stored procedure. Modifying the stored procedure invalidates the hash value so that the digital signature no longer matches. This prevents someone who does not have access to the private key from changing the stored procedure code. Therefore you must re-sign the procedure each time you modify it.
There are four steps involved in signing a module:
  1. Create a certificate using the Transact-SQL CREATE CERTIFICATE [certificateName] statement. This statement has several options for setting a start and end date and a password. The default expiration date is one year
  2. Create a database user associated with that certificate using the Transact-SQL CREATE USER [userName] FROM CERTIFICATE [certificateName] statement. This user exists in the database only and is not associated with a login.
  3. Grant the certificate user the required permissions on the database objects.
Note
A certificate cannot grant permissions to a user that has had permissions revoked using the DENY statement. DENY always takes precedence over GRANT, preventing the caller from inheriting permissions granted to the certificate user.
  1. Sign the procedure with the certificate using the Transact-SQL ADD SIGNATURE TO [procedureName] BY CERTIFICATE [certificateName] statement.
  1. Customizing Permissions with Impersonation in SQL Server
Many applications use stored procedures to access data, relying on ownership chaining to restrict access to base tables. You can grant EXECUTE permissions on stored procedures, revoking or denying permissions on the base tables. SQL Server does not check the permissions of the caller if the stored procedure and tables have the same owner. However, ownership chaining doesn't work if objects have different owners or in the case of dynamic SQL.
You can use the EXECUTE AS clause in a stored procedure when the caller doesn't have permissions on the referenced database objects. The effect of the EXECUTE AS clause is that the execution context is switched to the proxy user. All code, as well as any calls to nested stored procedures or triggers, executes under the security context of the proxy user. Execution context is reverted to the original caller only after execution of the procedure or when a REVERT statement is issued.

The Transact-SQL EXECUTE AS statement allows you to switch the execution context of a statement by impersonating another login or database user. This is a useful technique for testing queries and procedures as another user.
EXECUTE AS LOGIN = 'loginName';
EXECUTE AS USER = 'userName';
You must have IMPERSONATE permissions on the login or user you are impersonating. This permission is implied for sysadmin for all databases, and db_owner role members in databases that they own.

You can use the EXECUTE AS clause in the definition header of a stored procedure, trigger, or user-defined function (except for inline table-valued functions). This causes the procedure to execute in the context of the user name or keyword specified in the EXECUTE AS clause. You can create a proxy user in the database that is not mapped to a login, granting it only the necessary permissions on the objects accessed by the procedure. Only the proxy user specified in the EXECUTE AS clause must have permissions on all objects accessed by the module.
Note
Some actions, such as TRUNCATE TABLE, do not have grantable permissions. By incorporating the statement within a procedure and specifying a proxy user who has ALTER TABLE permissions, you can extend the permissions to truncate the table to callers who have only EXECUTE permissions on the procedure.
The context specified in the EXECUTE AS clause is valid for the duration of the procedure, including nested procedures and triggers. Context reverts to the caller when execution is complete or the REVERT statement is issued.
There are three steps involved in using the EXECUTE AS clause in a procedure.
  1. Create a proxy user in the database that is not mapped to a login. This is not required, but it helps when managing permissions.
CREATE USER proxyUser WITHOUT LOGIN
  1. Grant the proxy user the necessary permissions.
  2. Add the EXECUTE AS clause to the stored procedure or user-defined function.
CREATE PROCEDURE [procName] WITH EXECUTE AS 'proxyUser' AS ...
Note
Applications that require auditing can break because the original security context of the caller is not retained. Built-in functions that return the identity of the current user, such as SESSION_USER, USER, or USER_NAME, return the user associated with the EXECUTE AS clause, not the original caller.

You can use the Transact-SQL REVERT statement to revert to the original execution context.
The optional clause, WITH NO REVERT COOKIE = @variableName, allows you switch the execution context back to the caller if the @variableName variable contains the correct value. This allows you to switch the execution context back to the caller in environments where connection pooling is used. Because the value of @variableName is known only to the caller of the EXECUTE AS statement, the caller can guarantee that the execution context cannot be changed by the end user that invokes the application. When the connection is closed, it is returned to the pool.

In addition to specifying a user, you can also use EXECUTE AS with any of the following keywords.
  • CALLER. Executing as CALLER is the default; if no other option is specified, then the procedure executes in the security context of the caller.
  • OWNER. Executing as OWNER executes the procedure in the context of the procedure owner. If the procedure is created in a schema owned by dbo or the database owner, the procedure will execute with unrestricted permissions.
  • SELF. Executing as SELF executes in the security context of the creator of the stored procedure. This is equivalent to executing as a specified user, where the specified user is the person creating or altering the procedure.
References:
http://msdn.microsoft.com/
7 مهر 1393 برچسب‌ها: مقالات
SQL Server Security- 8th Section- Writing Secure Dynamic SQL

Number :IRCAR201407224

Date: 2014-07-18

  1. Introduction

SQL Server has many features that support creating secure database applications. Common security considerations, such as data theft or vandalism, apply regardless of the version of SQL Server you are using. Data integrity should also be considered as a security issue. If data is not protected, it is possible that it could become worthless if ad hoc data manipulation is permitted and the data is inadvertently or maliciously modified with incorrect values or deleted entirely. In addition, there are often legal requirements that must be adhered to, such as the correct storage of confidential information. Storing some kinds of personal data is proscribed entirely, depending on the laws that apply in a particular jurisdiction.

Each version of SQL Server has different security features, as does each version of Windows, with later versions having enhanced functionality over earlier ones. It is important to understand that security features alone cannot guarantee a secure database application. Each database application is unique in its requirements, execution environment, deployment model, physical location, and user population. Some applications that are local in scope may need only minimal security whereas other local applications or applications deployed over the Internet may require stringent security measures and ongoing monitoring and evaluation.

The security requirements of a SQL Server database application should be considered at design time, not as an afterthought. Evaluating threats early in the development cycle gives you the opportunity to mitigate potential damage wherever a vulnerability is detected.

Even if the initial design of an application is sound, new threats may emerge as the system evolves. By creating multiple lines of defense around your database, you can minimize the damage inflicted by a security breach. Your first line of defense is to reduce the attack surface area by never to granting more permissions than are absolutely necessary.

The topics in this section briefly describe the security features in SQL Server that are relevant for developers, with links to relevant topics in SQL Server Books Online and other resources that provide more detailed coverage.

  1. Writing Secure Dynamic SQL in SQL Server

SQL Injection is the process by which a malicious user enters Transact-SQL statements instead of valid input. If the input is passed directly to the server without being validated and if the application inadvertently executes the injected code, the attack has the potential to damage or destroy data.

Any procedure that constructs SQL statements should be reviewed for injection vulnerabilities because SQL Server will execute all syntactically valid queries that it receives. Even parameterized data can be manipulated by a skilled and determined attacker. If you use dynamic SQL, be sure to parameterize your commands, and never include parameter values directly into the query string.

2.1. Anatomy of a SQL Injection Attack


The injection process works by prematurely terminating a text string and appending a new command. Because the inserted command may have additional strings appended to it before it is executed, the malefactor terminates the injected string with a comment mark "--". Subsequent text is ignored at execution time. Multiple commands can be inserted using a semicolon (;) delimiter.

As long as injected SQL code is syntactically correct, tampering cannot be detected programmatically. Therefore, you must validate all user input and carefully review code that executes constructed SQL commands in the server that you are using. Never concatenate user input that is not validated. String concatenation is the primary point of entry for script injection.

Here are some helpful guidelines:
  • Never build Transact-SQL statements directly from user input; use stored procedures to validate user input.
  • Validate user input by testing type, length, format, and range. Use the Transact-SQL QUOTENAME() function to escape system names or the REPLACE() function to escape any character in a string.
  • Implement multiple layers of validation in each tier of your application.
  • Test the size and data type of input and enforce appropriate limits. This can help prevent deliberate buffer overruns.
  • Test the content of string variables and accept only expected values. Reject entries that contain binary data, escape sequences, and comment characters.
  • When you are working with XML documents, validate all data against its schema as it is entered.
  • In multi-tiered environments, all data should be validated before admission to the trusted zone.
  • Do not accept the following strings in fields from which file names can be constructed: AUX, CLOCK$, COM1 through COM8, CON, CONFIG$, LPT1 through LPT8, NUL, and PRN.
  • Use SqlParameter objects with stored procedures and commands to provide type checking and length validation.
  • Use Regex expressions in client code to filter invalid characters.

2.2. Dynamic SQL Strategies


Executing dynamically created SQL statements in your procedural code breaks the ownership chain, causing SQL Server to check the permissions of the caller against the objects being accessed by the dynamic SQL.

SQL Server has methods for granting users access to data using stored procedures and user-defined functions that execute dynamic SQL.

  • Using impersonation with the Transact-SQL EXECUTE AS clause.
  • Signing stored procedures with certificates.

2.2.1. EXECUTE AS


The EXECUTE AS clause replaces the permissions of the caller with that of the user specified in the EXECUTE AS clause. Nested stored procedures or triggers execute under the security context of the proxy user. This can break applications that rely on row-level security or require auditing. Some functions that return the identity of the user return the user specified in the EXECUTE AS clause, not the original caller. Execution context is reverted to the original caller only after execution of the procedure or when a REVERT statement is issued.

2.2.2. Certificate Signing


When a stored procedure that has been signed with a certificate executes, the permissions granted to the certificate user are merged with those of the caller. The execution context remains the same; the certificate user does not impersonate the caller. Signing stored procedures requires several steps to implement. Each time the procedure is modified, it must be re-signed.

2.2.3. Cross Database Access


Cross-database ownership chaining does not work in cases where dynamically created SQL statements are executed. You can work around this in SQL Server by creating a stored procedure that accesses data in another database and signing the procedure with a certificate that exists in both databases. This gives users access to the database resources used by the procedure without granting them database access or permissions.

References:
7 مهر 1393 برچسب‌ها: مقالات
Privacy Tips for Mobile Devices and Social Networks
IRCAR201407223


I. INTRODUCTION

As we increasingly connect our lives to the Internet with new devices and apps, understanding how to control our privacy has become a greater concern. You can see the privacy tips for Mobile Devices and Social Networks in the following post.

II. Mobile

Here are some tips and questions you should ask to help you protect your privacy when using a mobile device.

What information does your smartphone have about you?

Smartphones store and transmit a wide range of personal data which third parties can access–including contact lists, pictures, browsing history, certain identifying information and stored location data. Secure your phone with a long, strong and unique password, security software and other privacy features.

Do you keep a clean machine?

Smartphones can be vulnerable to viruses and malware that can compromise personal information. Protect your phone with security software and by updating operating systems and apps.

Would you want a malicious people to see or read it?

Think before you text. Keep in mind how the message might be read before you send it. Be aware that texts can be forwarded.

Are you respecting others’ privacy?

Make sure you have someone’s permission before taking pictures or videos of them with your phone. What you do online has the potential to affect everyone – at home, at work and around the world. Practicing good online habits benefits the global digital community.

Is the location service for your app necessary?

Many applications do not need geo-location enabled in order to provide the service. Opt-out of the location service feature on your phone. Own your online presence - It’s ok to limit how and with whom you share information.

Are you savvy about Wi-Fi hotspots?

Limit the type of business you conduct on your smartphone or tablet via Wi-Fi hotspots and adjust the security settings on your device to limit who can access your machine. Wi-Fi hotspots are convenient but can leave you vulnerable to intrusion.

III. Social Networking

Here are some tips and questions you should ask to help protect you when using social networking sites.

Do you own your online presence?

You don’t have to rely on “recommended” settings or default settings. Learn about the controls available and make your own decisions. It's okay to limit with whom you share your information. It is okay to not accept a friend request.

Do you know who will see what you post?

Consider who may have access to your profile: family, friends, friends of friends, your school, college admissions officers, and potential employers? Set the privacy and security settings to your personal comfort level for information sharing.

Did you know your online reputation can help you?

Create a strong, positive personal brand online for yourself online. Show your smarts, thoughtfulness, and mastery of the digital environment. This can help you with school admissions and during job searches.

Did you know your online reputation can hurt you?

What you post will be around for a long time. Think ahead and evaluate if what you post today is what you will want people to know about you in the future.

Did you know your privacy is only as protected as your least reliable friend allows it to be?

When you choose to share information with anyone in your networks, they can easily forward it or post. Make sure they will handle your information with care and trust. Avoid sharing compromising photos and information.

Is your password long, strong and unique?

Combine capital and lowercase letters with numbers and symbols in a unique password for each online account. Passwords are personal information that should not be shared.

Do you know what information you should not share on a profile page?

Your phone numbers, home address, full date of birth, travel plans, email address, class schedules, social security number, passwords, family financial information, bank or credit card numbers shouldn’t appear on your profile.

Do you know that your friends trust you with their information?

Post only about others what you would have them post about you. It’s the golden rule.

Reference:

http://www.staysafeonline.org/

18 مرداد 1393 برچسب‌ها: مقالات
صفحات: « 1 2 3 4 5 ... » »»