Suggérer une traduction
 
Suggestions d'autres utilisateurs :

progress indicator
Aucune autre suggestion.
TechNet Magazine > Accueil > Tous les numéros > 2009 > TechNet Magazine Janvier 2009 >  SharePoint à l'intérieur : comptes de sécurité ...
Affichage du contenu :  côte à côteAffichage du contenu : côte à côte
Ce contenu traduit automatiquement peut être modifié par les membres de la communauté. Nous vous invitons à améliorer la traduction en cliquant sur le lien « Modifier » associé aux phrases ci-dessous.
Inside SharePoint SharePoint Security Accounts
Pav Cherny


When using SharePoint security accounts, there is a high risk of creating weak system configurations that can expose an entire SharePoint environment. To help you deploy and secure SharePoint server farms correctly, Microsoft has published extensive information and detailed guidelines. The Office SharePoint Server Security guide , for example, comprises more than 300 pages about planning and implementing site and content hierarchies, authentication methods, security roles, administrator and service accounts, and many other security issues. The Windows SharePoint Services Security Account Requirements worksheet also provides essential information regarding security account configurations. If security is important to you, you definitely want to make sure to follow this worksheet.
Even with extensive documentation, configuring security accounts can be a difficult task. In fact, the default settings of single-server installations deviate from the worksheet's recommendations, and certain components, such as the E-mail Integration Web Service included in Windows SharePoint Services (WSS) 3.0, require elevated permissions on the server, which not only strays from the Microsoft security recommendations but is in direct conflict with security best practices and plain common sense. The SharePoint 3.0 Central Administration tool happily applies critical security account configurations without warnings, the Microsoft Baseline Security Analyzer (MBSA) does not detect the resulting weaknesses, and so it remains a challenge to secure a SharePoint server farm—and to keep it secure.
In this column, I put SharePoint security accounts under a microscope to show you how a weak configuration can give an attacker full control over all site collections and sites. This is a somewhat sensitive topic. On the one hand, I want to help you recognize the security challenges that surround SharePoint server configurations. After all, you must understand both the strengths and the weaknesses of your SharePoint environment if you want to secure it effectively.
On the other hand, I don't want to aid malicious people. For this reason, I am not providing any worksheets or custom tools with this column and I'll constrain source code discussions to basic topics that should be familiar to every professional ASP.NET developer. The source code snippets covered in this column should help you detect vulnerabilities, but not help anyone exploit them. Even with limited programming skills, you should be able to use these snippets to create custom ASP.NET pages if you have Microsoft Office SharePoint Designer 2007.
A trial version of Microsoft Office SharePoint Designer 2007 is available online. I invite you to configure a test lab according to your own preferences, secure it as best as you can, and then run the code snippets for verification purposes. Let's see how secure your SharePoint sites are!

Application Pools and Security Accounts
Security accounts are at the very core of the SharePoint request-processing model. They define the security context of the IIS worker processes that run the SharePoint Web applications. When you create a SharePoint Web application, you must specify, among other things, an application pool with associated security account credentials and a SharePoint database with an associated authentication method. If you use Windows authentication (recommended), SharePoint automatically grants the specified security account dbOwner permissions on the content database so that the IIS worker process running the SharePoint Web application can gain access to the site collections and sites hosted in this database. Otherwise, you must provide explicit SQL Server credentials.
In any case, SharePoint site collections and sites are virtual constructs. Physically, they correspond to database records. If you know the account name and password to establish a direct SQL Server connection to the content database, you can gain full access to all its site collections and site data regardless of permissions and access controls defined at the SharePoint level. SharePoint cannot block you because you are establishing a direct connection to the database server, as illustrated in Figure 1. The security account is therefore a prime target for an attack.
Figure 1 Bypassing SharePoint site collections and sites to access data
To mitigate security risks, Microsoft recommends that you configure separate applications pools (and security accounts) for site collections with authenticated and anonymous content and to isolate applications that store passwords or where users have great liberty to create and administer sites and to collaborate on content. By following this configuration advice, the underlying idea is that an attacker who gains control over one application pool will not then implicitly have universal access to all data hosted in the SharePoint farm. SharePoint site collections and sites in other databases are still out of reach, provided you use separate security accounts for their associated Web applications.
Microsoft first introduced the concept of worker process isolation based on applications pools with IIS 6.0 and states that IIS has not suffered a single critical security vulnerability ever since. This is very reassuring, so be sure to take advantage of application pools in SharePoint farms. Keep in mind, however, that IIS Web sites and SharePoint Web applications are not synonymous. While you can isolate IIS Web sites, you cannot isolate SharePoint Web applications from each other.
Genuine isolation exists only if Web sites do not share resources, yet SharePoint Web applications always have resources in common, such as the farm's configuration database. As illustrated in Figure 2, gaining control over a SharePoint security account implies the ability to access the SharePoint configuration database. That access capability should make you feel uncomfortable if you deployed your SharePoint farm without giving proper thought to the protection of your security accounts, especially if you are hosting site collections and sites from different internal or external customers in a shared environment.
Figure 2 Relationship between SharePoint Web applications, configuration database, and content databases

Running Custom Code on SharePoint Servers
Out of the box, SharePoint doesn't disclose security account information; it takes malicious code to discover the details. As we all know, security vulnerabilities can enable attackers to upload malicious code, but sometimes intrusion is even easier.
In the simplest case, an attacker might be able to log on to a SharePoint server locally or via Terminal Server and copy malicious code into the %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\TEMPLATE\Layouts folder. Note that SharePoint includes this folder as a virtualized subfolder in every SharePoint site.
In another scenario, a SharePoint administrator might unknowingly introduce malicious code by deploying a custom SharePoint solution from a questionable source without proper testing and code verification. Inline ASP.NET code embedded in master and content pages is also cause for concern. By default, SharePoint does not process server-side scripts, but anyone with write-access to a SharePoint Web application's web.config file can change the rules for processing server-side scripts. You need only add a PageParserPath entry to the web.config file's <PageParserPaths> section. How exactly does the PageParserPath entry work?
Let's suppose a developer who is using SharePoint calls you and complains about an error message he gets while developing a custom ASP.NET page that states "Code blocks are not allowed in this file." You search the Internet and find the solution in a newsgroup or blog site:


<PageParserPath VirtualPath="/*" CompilationMode="Always" AllowServerSideScript="true" IncludeSubFolders="true" />
Perhaps you ignore the security warnings or perhaps the security implications aren't even mentioned. No matter, you add this line to your web.config file and now everybody is happy because you solved the problem.
Unwittingly, however, you also just opened an avenue to run any custom code in ASP.NET pages with full trust. If an attacker now uploads a malicious ASP.NET page, the SharePoint environment is in jeopardy. As indicated in Figure 3, it is irrelevant where in a site collection hierarchy an attacker has the permission to upload a page—it can be an innocent-looking small team site. The attack always affects the Web application and possibly the entire server farm because both content database and configuration database are accessible.

Figure 3
Figure 3 Enabling inline ASP.NET code can compromise a SharePoint Web application

About Dr. Jekyll and Mr. Hyde
So how does an attacker gain access to content and configuration databases without explicitly knowing the security account credentials? It's actually relatively straightforward. The IIS worker process that runs the SharePoint Web application impersonates the SharePoint user and uses the resulting thread token for access checks. For example, Dr. Jekyll can access all those SharePoint resources that his security token is permitted to access. But the SharePoint Web application also has the process token of the IIS worker process, which is the security token of the SharePoint security account.
It is Mr. Hyde who shows up when you revert impersonation by calling the static WindowsIdentity.Impersonate method, and passing in a zero pointer, as illustrated in Figures 4 and 4a. Dr. Jekyll has no direct access to the databases, but Mr. Hyde does. The road is clear for SQL Server connections and T-SQL queries.
Figure 4 SharePoint Web applications have two security contexts (Click the image for a larger view)
private string GetMrHyde()
{
    string retVal = string.Empty;
    retVal = "Dr Jekyll is: " + WindowsIdentity.GetCurrent().Name + "<br>";

    WindowsImpersonationContext impCtx = WindowsIdentity.Impersonate(IntPtr.Zero);

    retVal += "Mr Hyde is: " + WindowsIdentity.GetCurrent().Name + "<br>";

    impCtx.Undo();
    return retVal;
}

Security Accounts and Process Isolation
Application pools and security accounts cannot help you protect site collections and sites placed in a Web application configured to run unverified code. Their purpose is to mitigate, by means of process isolation, the impact of an exploit on one site that allows an attacker to inject code onto the server to attack other sites. Process isolation can help to achieve this goal, but it requires you to place the other sites in separate Web applications that run in application pools with different security accounts.
You must adequately protect the account credentials, otherwise the configuration effort is pointless. One easy way to deliver these sensitive security credentials straight into the wrong hands is to grant application pool accounts access to the IIS metabase, which is required to run the Directory Management Service—a part of the E-mail Integration Web service. If the application pool account has metabase access, an attacker can revert impersonation and then retrieve all the accounts and passwords in clear text, as illustrated in Figures 5 and 5a. The entire server farm is lost because the attacker can now bypass process isolation by running malicious code under any of these security accounts and establishing SQL Server connections to all content databases.
Figure 5 Retrieving security account information from the IIS metabase
private string GetMetabaseAppPoolIDs()
{
        WindowsImpersonationContext impCtx = WindowsIdentity.Impersonate(IntPtr.Zero);
        string retVal = string.Empty;
        try
        {
            string metabasePath = "IIS://localhost/w3svc/AppPools";
            DirectoryEntry appPools = new DirectoryEntry(metabasePath);
            foreach (DirectoryEntry appPool in appPools.Children)
            {
            switch (int.Parse(appPool.Properties["AppPoolIdentityType"].Value.ToString()))
            {
                case 0: // Local System
                    retVal += "<br>" + appPool.Name
                        + " (Local System)";
                    break;
                case 1: // Local Service
                    retVal += "<br>" + appPool.Name
                        + " (Local Service)";
                    break;
                case 2: // Network Service
                     retVal += "<br>" + appPool.Name
                        + " (Network Service)";
                     break;
                case 3: // Custom 
                    retVal += "<br>" + appPool.Name
                        + " (" + appPool.Properties["WAMUserName"].Value
                        + " [Pwd: " + appPool.Properties["WAMUserPass"].Value
                        + "])";
                    break;
               }
            }
         }
        catch (Exception ee)
         {
        retVal = "Metabase " + ee.Message;
         }

        impCtx.Undo();
}
If you're interested in a Directory Management Service solution that doesn't require metabase access, you should look up my September 2008 column, " SharePoint Directory Integration ."

Security Accounts in the Configuration Database
If you follow the rule not to grant application pool accounts administrative permissions or even so much as read access to the IIS metabase on your SharePoint servers, the code in Figure 5 only yields an Access is denied message. But security account information is also available in the configuration database and Mr. Hyde has access to this database, as explained earlier.
You can't deny SharePoint security accounts access to the configuration database nor can you deny access to the registry key that stores the corresponding SQL Server connection string. The connection string might not immediately work if you use SQL Server 2005 Express, but you can derive the correct data source information from the current SharePoint site collection (SPContext.Current.Site.ContentDatabase.DatabaseConnectionString) and the name of the configuration database corresponds to the name of the local farm (SPFarm.Local.Name).
Unfortunately, these little hurdles don't stop an attack. Regardless of whether you use SQL Server or SQL Server Express, Mr. Hyde can retrieve the information displayed in Figures 6 and 6a. Note that the password is encrypted, however, so the attack has not yet fully succeeded.
Figure 6 Getting security account information from the configuration metabase
private string EnumAppPoolAccounts()
{
    string retVal = string.Empty;
    try
    {
       WindowsImpersonationContext impCtx = WindowsIdentity.Impersonate(IntPtr.Zero);

       string regConfigDB = @"SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Secure\ConfigDB";
       RegistryKey keyConfigDB = Registry.LocalMachine.OpenSubKey(regConfigDB);

       string ConfigDB = (string)keyConfigDB.GetValue("dsn");

       SqlConnection sqlConn = new SqlConnection(ConfigDB);
       sqlConn.Open();

       SqlCommand sqlCmd = new SqlCommand("SELECT Name, Properties FROM Objects"
          + " WHERE ClassId = 'B8369089-08AD-4978-B1CB-C597B5E90F64'", sqlConn);
       sqlCmd.CommandType = System.Data.CommandType.Text;
       SqlDataReader sqlReader = sqlCmd.ExecuteReader();

          while (sqlReader.Read())
          {
             retVal += "<br>" + sqlReader.GetString(0);
             string appPoolXML = sqlReader.GetString(1);
             if (!string.IsNullOrEmpty(appPoolXML))
             {

                 XmlDocument xmlDoc = new XmlDocument();
                 xmlDoc.LoadXml(appPoolXML);

                 XmlElement root = xmlDoc.DocumentElement;
                 XmlNode ndType = root.SelectSingleNode("/object/fld[@name=                   'm_IdentityType']");
                 if (ndType != null && ndType.InnerText.ToLower() != "specificuser")
                 {
                     retVal += " (" + ndType.InnerText + ")";
                 }
                 else
                 {
                     retVal += " (" 
                         + root.SelectSingleNode("/object/sFld[@name='m_Username']").InnerText
                         + " [Pwd: " 
                         + root.SelectSingleNode("/object/fld[@name='m_Password']").InnerText
                         + "])";
                 }
             }
          }
          sqlReader.Close();
          sqlConn.Close();
          impCtx.Undo();
    }
    catch (Exception ee)
    {
          retVal = ee.Message;
    }
    return retVal;
}
But even without decrypting passwords, application pools that use the same security account are already recognizable. For example, in Figure 6, the application pools SharePoint Central Administration v3 and SharePoint—80 use the Network Service account and if SharePoint—80 happens to be the compromised Web application, then SharePoint Central Administration v3 is compromised as well. The corresponding security account is the Central Administration account, which has elevated permissions on the SharePoint server.
It should not be used for standard Web application pools, yet the SharePoint Products and Technologies Configuration Wizard applies this configuration in a single-server installation by default. Therefore, it's very important that you review and, if necessary, change the security account configuration in your SharePoint environment. More information on this topic is outlined in detail in the Microsoft Knowledge Base article " How to Change Service Accounts and Service Account Passwords in SharePoint Server 2007 and in Windows SharePoint Services 3.0 ."

Security Accounts and Credential Keys
So what's the big deal about the Central Administration account? Most importantly, unlike standard application pool accounts, the Central Administration account has access to the registry location that stores the credential key to decrypt the security account passwords.
Figure 7 shows this parameter and its default security settings. As you can see, local Administrators, the WSS_RESTRICTED_WPG group (which contains the Central Administration account), and the SYSTEM account have access to this key and this implies that your SharePoint Web applications should not use accounts with local administrator permissions, the Central Administration account, or the SYSTEM account. SharePoint Web applications should not be able to access the credential key.
Figure 7 Permission assignments to access the FarmAdmin registry key
Unfortunately, however, this is no guarantee that a skilled attacker cannot determine the CredentialKey or security account passwords, such as through SYSTEM token hijacking, password cracking, or simply by placing malicious code in master pages or content pages to export the credential key to an unprotected location and then waiting for a user with local administrator permissions to access the site. As you can see, it's important that you don't allow unverified code on your servers.
SYSTEM token hijacking deserves some more detailed explanation because you can prevent this form of attack if you avoid using the built-in system accounts, such as Network Service, for your SharePoint Web applications. In fact, Cesar Cerrudo, founder and CEO of Argeniss, discovered this vulnerability, and he demonstrated the exploit at the HITBSecConf2008 Deep Knowledge Security Conference in Dubai, United Arab Emirates. Cesar showed how an ASP.NET Web application running under the Network Service account can inject a DLL into the Remote Procedure Call (RPC) service and then hijack the security token of a thread in the RPC service that runs at SYSTEM privilege level.
After this, an attacker then only needs to pass the hijacked SYSTEM security token to the WindowsIdentity.Impersonate method to gain access to the CredentialKey registry parameter and other protected resources. Microsoft confirmed the vulnerability, so you should avoid using the Network Service account for your SharePoint Web applications.

Don't Break the Law
The 10 Immutable Laws of Security were published by the Microsoft Security Response Center a long time ago, and they still apply today. Jesper M. Johansson recently wrote a three-part series called " Revisiting the 10 Immutable Laws of Security ." You should keep these laws in mind when designing your SharePoint server farms, and you should also follow the SharePoint security guidelines and worksheets to apply reliable security account configurations.
In a nutshell: use strong passwords, don't grant security accounts elevated permissions on your SharePoint servers, change passwords frequently (including the farm credentials), and keep in mind that there is no absolute isolation between SharePoint Web applications that use common resources, just as there is no absolute computer security. Moreover, don't change the server code processing rules, keep unverified assemblies away from your servers, and follow the Windows SharePoint Services Security Account Requirements worksheet in your security account configuration, and you might be able to consider your SharePoint environment reasonably secure.
However, if strict separation of site content is a requirement for your organization, I recommend that you host the corresponding site collections in separate server farms, possibly in separate Active Directory forests and SQL Server environments.

Pav Cherny is an IT expert and author specializing in Microsoft technologies for collaboration and unified communication. His publications include white papers, product manuals, and books with a focus on IT operations and system administration. Pav is President of Biblioso Corporation, a company that specializes in managed documentation and localization services.

SharePoint à l'intérieur Comptes de sécurité de SharePoint
Pav Cherny


Lorsque vous utilisez des comptes de sécurité de SharePoint, il y a un risque élevé de création de configurations système faibles qui peuvent exposer un environnement SharePoint ensemble. Pour vous aider à déployer et sécuriser des batteries de serveurs SharePoint correctement, Microsoft a publié des informations détaillées et des instructions détaillées. Le Office SharePoint Server Security guide , par exemple, comporte plus de 300 pages sur de planification et implémentation de hiérarchies de site et de contenu, méthodes d'authentification, rôles de sécurité, administrateur et comptes de service et plusieurs autres problèmes de sécurité. Le Feuille de calcul exigences du compte Windows SharePoint Services de sécurité fournit également les informations essentielles concernant la sécurité configurations des comptes. Si la sécurité est importante pour vous, vous souhaitez certainement Veillez à suivre cette feuille de calcul.
Même avec une documentation complète, la configuration de comptes de sécurité peut être une tâche difficile. En fait, modifier les paramètres par défaut des installations à serveur unique à partir de recommandations de la feuille de calcul, et certains composants, tels que le service Web d'intégration E-mail inclus dans Windows SharePoint Services (WSS) 3.0, nécessitent des autorisations avec des privilèges élevés sur le serveur, ce qui not only strays dans les recommandations de sécurité Microsoft mais est en conflit direct avec les bonnes pratiques de sécurité et common sense ordinaire. L'outil d'administration centrale de SharePoint 3.0 s'applique Heureusement configurations des comptes sans avertissements sécurité critiques, Microsoft Baseline Security Analyzer (MBSA) ne pas détecter les points faibles qui en résulte et donc il reste un défi pour sécuriser une batterie de serveurs SharePoint, en conservant sécurisé.
Dans cette chronique, je placer des comptes de sécurité de SharePoint sous un microscope pour vous montrer comment une configuration faible peut donner un utilisateur malveillant plein contrôle sur toutes les collections de sites et sites. Ceci est un sujet un peu la casse. D'une part, je souhaite pouvoir reconnaître les défis de sécurité qui entourent les configurations de serveurs SharePoint. Après tout, vous devez comprendre les forces et les points faibles de votre environnement SharePoint si vous souhaitez sécuriser efficacement.
D'autre part, je ne souhaite aider les utilisateurs malveillants. Pour cette raison, je ne suis pas fournir les feuilles de calcul ou les outils personnalisés cette colonne et je vous contraindre les discussions sur le code source vers les rubriques base qui doivent être familiers pour chaque développeur ASP.NET professionnel. Les extraits de code source abordée dans cette colonne doit Aide vous détecter des problèmes, mais pas vous aider à toute personne exploiter les. Même avec compétences de programmation limitées, vous devriez pouvoir utiliser ces extraits de code pour créer des pages ASP.NET personnalisées si vous avez Microsoft Office SharePoint Designer 2007.
A version d'évaluation de Microsoft Office SharePoint Designer 2007 est disponible en ligne. Je vous invitons à configurer un laboratoire de test en fonction de vos propres préférences de, sécuriser les meilleures que vous le pouvez, puis exécutez les extraits de code fins de vérification. Nous allons voir comment sécurisé vos sites SharePoint sont !

Comptes de sécurité et de pools d'applications
Les comptes de sécurité sont au cœur très du modèle requête-traitement SharePoint. Ils définissent le contexte de sécurité des processus de travail IIS exécuter des applications Web SharePoint. Lorsque vous créez une SharePoint application Web, vous devez spécifier, entre autres, un pool d'applications avec informations d'identification sécurité associé compte et une base de données SharePoint avec une méthode d'authentification associés. Si vous utilisez l'authentification Windows (recommandée), SharePoint accorde automatiquement le compte de sécurité spécifiée dbOwner autorisations sur la base de données de contenu afin que le processus de traitement IIS exécution de l'application Web SharePoint peuvent y accéder aux collections de sites et des sites hébergés dans cette base de données. Dans le cas contraire, vous devez fournir des informations d'identification SQL Server explicites.
En tout cas, les collections de sites SharePoint et sites sont des constructions virtuelles. Physiquement, ils correspondent aux enregistrements de base de données. Si vous connaissez le nom de compte et le mot de passe pour établir une connexion SQL Server directe à la base de données de contenu, vous pouvez accéder complet à tous les collections de sites et ses données de site indépendamment d'autorisations et des contrôles d'accès définis au niveau du SharePoint. SharePoint ne peut pas vous empêcher parce que vous établissez une connexion directe au serveur de base de données, comme illustré dans la figure 1 . Le compte de sécurité est donc une cible de prime pour une attaque.
Figure 1 contourner SharePoint site collections et des sites pour accéder aux données
Pour atténuer les risques de sécurité, Microsoft recommande de configurer applications distinctes pools (et comptes de sécurité) pour les collections de sites authentifié et anonyme contenu et pour isoler les applications que mots de passe banque ou où les utilisateurs ont très liberty créer et gérer des sites et de collaboration sur le contenu. En suivant ce conseil de configuration, l'idée sous-jacente est qu'un pirate qui réussit à contrôler un pool d'applications pas puis implicitement auront universel accès à toutes les données hébergées dans la batterie de serveurs SharePoint. Collections de sites SharePoint et sites d'autres bases de données sont toujours pas atteindre, condition que vous utilisez des comptes de sécurité distinct pour leurs applications Web associées.
Microsoft a tout d'abord introduit le concept d'isolation de processus de travail basé sur les pools d'applications avec IIS 6.0 et états que IIS n'a pas rencontré un problème de sécurité critique unique jamais depuis. C'est très reassuring, par conséquent, veillez à tirer parti des pools d'applications de batteries de serveurs SharePoint. Gardez à l'esprit, toutefois, que sites Web IIS et les applications Web SharePoint ne sont pas synonymes. Pendant que vous pouvez isoler les sites Web IIS, vous ne pouvez pas isoler des applications Web SharePoint les unes des autres.
Isolation authentique existe uniquement si sites Web ne partagent pas de ressources, mais les applications Web SharePoint toujours ont ressources en commun, comme base de données configuration de la batterie. Comme illustré à la figure 2 , de plus de contrôle sur un compte de sécurité de SharePoint implique la possibilité d'accéder à la base de données de configuration SharePoint. Cette fonctionnalité d'accès Assurez-vous vous pensez sensation Si déployé votre batterie sans donner pensée appropriée la protection de vos comptes de sécurité, en particulier si vous hébergez des collections de sites et les sites des clients internes ou externes différents dans un environnement partagé.
La figure 2 une relation entre les applications Web SharePoint, base de données de configuration et bases de données de contenu

Exécution de code personnalisé sur SharePoint Server
De la zone SharePoint n'est pas divulguer des informations de compte sécurité ; elle prend le code malveillant à découvrir les détails. Comme nous le savez, des failles de sécurité permettent de pirates à télécharger un code malveillant, mais parfois intrusions sont encore plus facile.
Dans le cas plus simple, un utilisateur malveillant peut être en mesure de se connecter à un serveur SharePoint localement ou via Terminal Server et copie le code malveillant dans le dossier %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\TEMPLATE\Layouts. Notez que SharePoint inclut ce dossier comme sous-dossier virtualisé dans chaque site SharePoint.
Dans un autre scénario, un administrateur SharePoint peut involontairement présente un code malveillant en déployant une solution SharePoint personnalisée à partir d'une source douteux sans test approprié et vérification de code. Code en ligne ASP.NET incorporé dans les pages maîtres et de contenu est également cause du problème. Par défaut, SharePoint ne traite pas les scripts côté serveur, mais toute personne ayant accès en écriture au fichier web.config une application Web SharePoint peut modifier les règles de traitement des scripts côté serveur. Vous devez uniquement ajouter une entrée PageParserPath de fichier web.config <pageparserpaths> section. Comment exactement l'entrée PageParserPath fonctionne-t-il ?
Nous allons supposez qu'un développeur qui est à l'aide de SharePoint vous appelle et complains sur un message d'erreur il récupère pendant le développement d'une page ASP.NET personnalisée indiquant « blocs de code sont non autorisés dans ce fichier. » Vous rechercher sur Internet et rechercher la solution dans un site de groupe de discussion ou un blog :


<PageParserPath VirtualPath="/*" CompilationMode="Always" AllowServerSideScript="true" IncludeSubFolders="true" />
Peut-être vous ignorez les avertissements de sécurité ou peut-être les implications de sécurité ne sont pas encore mentionnées. Quel, que vous ajoutez cette ligne à votre fichier web.config et tout le monde est désormais bon car vous parvient à résoudre le problème.
Unwittingly, toutefois, vous aussi simplement ouvert un moyen pour exécuter tout code personnalisé dans les pages ASP.NET avec une autorisation totale. Si un utilisateur malveillant téléchargements maintenant une page ASP.NET malveillante, l'environnement SharePoint est en péril. Comme indiqué dans la figure 3 , il est inutile où dans une hiérarchie du site collection un utilisateur malveillant possède l'autorisation pour télécharger une page, il peut être un innocent-recherche site petite équipe. L'attaque affecte toujours l'application Web et éventuellement toute la batterie car la base de données de contenu et de base de données de configuration sont accessibles.

La figure 3
La figure 3 Activation en ligne ASP.NET code peut compromettre une application Web SharePoint

Sur Dr. Jekyll et m. Hyde
Comment agresseur accéder aux bases de données de contenu et de configuration sans connaître explicitement les informations d'identification du compte de sécurité ? Il est en fait relativement simple. Le processus de travail IIS qui s'exécute l'application Web SharePoint emprunte l'identité de l'utilisateur de SharePoint et utilise le jeton de thread résultant pour les vérifications d'accès. Par exemple, Dr. Jekyll peuvent accéder aux toutes les ressources SharePoint que son jeton de sécurité est autorisé à accéder. Mais l'application Web SharePoint a également le jeton de processus du processus de travail IIS, qui est le jeton de sécurité du compte de sécurité de SharePoint.
Il est M. Hyde qui s'affiche lorsque vous revenir l'emprunt d'identité en appelant la méthode WindowsIdentity.Impersonate statique et en transmettant un pointeur nul comme illustré dans les 4 chiffres et 4 a . Dr. Jekyll n'a aucun accès direct à la bases de données, mais M. Hyde ne. La route est désactivée pour les connexions SQL Server et les requêtes T-SQL.
La figure 4 applications Web SharePoint ont deux contextes de sécurité (cliquez sur l'image pour l'agrandir)
private string GetMrHyde()
{
    string retVal = string.Empty;
    retVal = "Dr Jekyll is: " + WindowsIdentity.GetCurrent().Name + "<br>";

    WindowsImpersonationContext impCtx = WindowsIdentity.Impersonate(IntPtr.Zero);

    retVal += "Mr Hyde is: " + WindowsIdentity.GetCurrent().Name + "<br>";

    impCtx.Undo();
    return retVal;
}

Comptes de sécurité et isolation de processus
Pools d'applications et comptes de sécurité ne peut pas vous aider protéger les collections de sites et les sites placés dans une application Web configurée pour s'exécuter du code non vérifié. Leur but est de réduire, par le biais d'isolation du processus, l'impact d'un système d'exploitation sur un site qui permet à un agresseur à injecter du code sur le serveur aux attaques d'autres sites. Isolation du processus peut vous aider à atteindre cet objectif, mais elle nécessite vous permet de placer les autres sites dans les applications Web distinctes qui s'exécutent dans pools d'applications avec des comptes de sécurité.
Vous devez protéger correctement les informations d'identification du compte, sinon, l'effort de configuration est inutile. Une facile façon à fournir ces informations d'identification sécurité sensibles directement dans les mains incorrects consiste à accorder accès aux comptes de pool d'applications à la métabase IIS, qui est requise pour exécuter le service de gestion d'annuaire, une partie du service Web d'intégration courrier électronique. Si le compte du pool d'applications dispose d'un accès métabase, un utilisateur malveillant peut rétablir l'emprunt d'identité et puis extraire tous les comptes et mots de passe en texte clair, comme illustré dans les figures 5 et 5 a . La batterie de serveurs serveur entier est perdue parce que l'utilisateur malveillant peut ignorer maintenant Isolation du processus en exécutant un code malveillant sous un de ces comptes de sécurité et établir des connexions SQL Server à toutes les bases de données contenus.
La figure 5 Récupération des informations de compte de sécurité à partir de la métabase IIS
private string GetMetabaseAppPoolIDs()
{
        WindowsImpersonationContext impCtx = WindowsIdentity.Impersonate(IntPtr.Zero);
        string retVal = string.Empty;
        try
        {
            string metabasePath = "IIS://localhost/w3svc/AppPools";
            DirectoryEntry appPools = new DirectoryEntry(metabasePath);
            foreach (DirectoryEntry appPool in appPools.Children)
            {
            switch (int.Parse(appPool.Properties["AppPoolIdentityType"].Value.ToString()))
            {
                case 0: // Local System
                    retVal += "<br>" + appPool.Name
                        + " (Local System)";
                    break;
                case 1: // Local Service
                    retVal += "<br>" + appPool.Name
                        + " (Local Service)";
                    break;
                case 2: // Network Service
                     retVal += "<br>" + appPool.Name
                        + " (Network Service)";
                     break;
                case 3: // Custom 
                    retVal += "<br>" + appPool.Name
                        + " (" + appPool.Properties["WAMUserName"].Value
                        + " [Pwd: " + appPool.Properties["WAMUserPass"].Value
                        + "])";
                    break;
               }
            }
         }
        catch (Exception ee)
         {
        retVal = "Metabase " + ee.Message;
         }

        impCtx.Undo();
}
Si vous êtes intéressé par une solution de service de gestion d'annuaire qui ne nécessite l'accès métabase, vous devez rechercher des mon article de septembre 2008 " Intégration Directory SharePoint ."

Comptes de sécurité dans la base de données de configuration
Si vous suivez la règle pas accorder des autorisations d'administration des comptes pool d'applications ou même ainsi, bien que les accès de lecture à la métabase IIS sur vos serveurs SharePoint, le code de produit seul figure 5 accès est refusé le message. Mais les informations de compte de sécurité sont également disponibles dans la base de données de configuration et M. Hyde a accès à cette base de données, comme expliqué plus haut.
Vous ne pouvez pas refuser le SharePoint sécurité comptes d'accès à la base de données de configuration ni pouvez vous refusez l'accès à la clé de Registre qui stocke la chaîne de connexion SQL Server correspondante. La chaîne de connexion ne peut pas immédiatement fonctionner si vous utilisez SQL Server 2005 Express, mais vous pouvez obtenir les informations de source de données approprié de la collection de sites SharePoint en cours (SPContext.Current.Site.ContentDatabase.DatabaseConnectionString) et le nom de la base de données de configuration correspond au nom de la batterie locale (SPFarm.Local.Name).
Malheureusement, ces obstacles peu ne pas arrêter une attaque. Indépendamment de si vous utilisez SQL Server ou SQL Server Express, M. Hyde pouvez récupérer les informations affichées dans 6 chiffres et 6 . Notez que le mot de passe est chiffré, toutefois, afin de l'attaque n'a pas encore complètement réussi.
La figure 6 obtenir des informations de compte de sécurité de la configuration de métabase
private string EnumAppPoolAccounts()
{
    string retVal = string.Empty;
    try
    {
       WindowsImpersonationContext impCtx = WindowsIdentity.Impersonate(IntPtr.Zero);

       string regConfigDB = @"SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Secure\ConfigDB";
       RegistryKey keyConfigDB = Registry.LocalMachine.OpenSubKey(regConfigDB);

       string ConfigDB = (string)keyConfigDB.GetValue("dsn");

       SqlConnection sqlConn = new SqlConnection(ConfigDB);
       sqlConn.Open();

       SqlCommand sqlCmd = new SqlCommand("SELECT Name, Properties FROM Objects"
          + " WHERE ClassId = 'B8369089-08AD-4978-B1CB-C597B5E90F64'", sqlConn);
       sqlCmd.CommandType = System.Data.CommandType.Text;
       SqlDataReader sqlReader = sqlCmd.ExecuteReader();

          while (sqlReader.Read())
          {
             retVal += "<br>" + sqlReader.GetString(0);
             string appPoolXML = sqlReader.GetString(1);
             if (!string.IsNullOrEmpty(appPoolXML))
             {

                 XmlDocument xmlDoc = new XmlDocument();
                 xmlDoc.LoadXml(appPoolXML);

                 XmlElement root = xmlDoc.DocumentElement;
                 XmlNode ndType = root.SelectSingleNode("/object/fld[@name=                   'm_IdentityType']");
                 if (ndType != null && ndType.InnerText.ToLower() != "specificuser")
                 {
                     retVal += " (" + ndType.InnerText + ")";
                 }
                 else
                 {
                     retVal += " (" 
                         + root.SelectSingleNode("/object/sFld[@name='m_Username']").InnerText
                         + " [Pwd: " 
                         + root.SelectSingleNode("/object/fld[@name='m_Password']").InnerText
                         + "])";
                 }
             }
          }
          sqlReader.Close();
          sqlConn.Close();
          impCtx.Undo();
    }
    catch (Exception ee)
    {
          retVal = ee.Message;
    }
    return retVal;
}
Mais même sans déchiffrer le mot de passe, pools d'applications qui utilisent le même compte de sécurité sont déjà reconnus. Par exemple, dans la figure 6 , l'application pools l'administration centrale de SharePoint v3 et SharePoint, 80 utiliser le compte Service réseau et si SharePoint — 80 se trouve être l'application Web compromise, puis v3 de l'administration centrale de SharePoint est compromis ainsi. Le compte de sécurité correspondante est le compte de l'administration centrale, qui possède des autorisations élevés sur le serveur SharePoint.
Il ne doit pas être utilisé pour les pools d'applications Web standard, mais les produits SharePoint et Assistant Configuration de technologies applique cette configuration dans une installation serveur unique par défaut. Par conséquent, il est très important que vous examinez et, si nécessaire, modifiez la configuration de compte de sécurité dans votre environnement SharePoint. Plus d'informations sur ce sujet est décrit dans en détail dans l'article de la base de connaissances » Comment modifier comptes de service et les mots de service passe de comptes dans SharePoint Server 2007 et dans Windows SharePoint Services 3.0 ."

Comptes de sécurité et les clés d'informations d'identification
Quel est donc la beaucoup big sur le compte de l'administration centrale ? Plus important encore, contrairement aux comptes de pool d'application standard, le compte de l'administration centrale a accès à l'emplacement de Registre qui stocke la clé Informations d'identification pour déchiffrer le mot de passe de compte sécurité.
la figure 7 illustre ce paramètre et par défaut les paramètres de sécurité. Que vous pouvez le voir, les administrateurs locaux, le groupe WSS_RESTRICTED_WPG (qui contient le compte de l'administration centrale) et le compte SYSTEM a accès à cette clé et cela implique que vos applications Web SharePoint doivent d'utiliser comptes avec des autorisations d'administrateur local, le compte de l'administration centrale ou le compte système. Applications Web SharePoint ne doivent pas pouvoir accéder à la clé informations d'identification.
La figure 7 affectations d'autorisations pour accéder à la clé de Registre FarmAdmin
Malheureusement, cependant, ne c'est aucune garantie qu'un pirate compétent ne peut pas déterminer mots des sécurité ou CredentialKey passe des comptes, tels que via détournement de jeton système, mot de passe trouvé, ou simplement en plaçant un code malveillant dans les pages maîtres ou pages de contenu pour exporter la clé informations d'identification à un emplacement non protégé et puis attend un utilisateur disposant d'autorisations d'administrateur local pour accéder au site. Comme vous pouvez le voir, il est important que vous ne pas autoriser le code non vérifié sur vos serveurs.
Détournement de jeton système nécessite une explication plus détaillée, car vous pouvez empêcher cette forme d'attaque si il préférable d'utiliser les comptes système intégré, tel que Service réseau, pour vos applications Web SharePoint. En fait, Cesar Cerrudo, fondateur et directeur général de Argeniss découvert ce problème, il a démontré le système d'exploitation à la HITBSecConf2008 long connaissances sécurité conférence dans Dubai, Émirats arabes unis. Cesar montré comment une application Web ASP.NET qui s'exécute sous le compte service réseau peut injecter une DLL dans le service Appel de procédure distante (RPC) et ensuite détourner le jeton de sécurité d'un thread dans le service RPC qui s'exécute au niveau de privilège système.
Après cela, un utilisateur malveillant puis ne doit transmettre le jeton de sécurité système hijacked à la méthode WindowsIdentity.Impersonate pour pouvoir utiliser le paramètre de Registre CredentialKey et autres ressources protégées. Microsoft confirmé le problème, donc vous évitez d'utiliser le compte service réseau de vos applications Web SharePoint.

Ne pas rompre la loi
Le 10 Lois immuables de sécurité a été publié par Microsoft Security Response Center longtemps et toujours appliquer dès aujourd'hui. Jesper A M. Johansson récemment écrit une série en trois parties appelée » Reconsidérer les 10 lois immuables de sécurité ." Vous devez conservez ces lois ESPRIT lorsque vous créez votre batteries de serveurs SharePoint et vous devez également suivre les instructions de sécurité de SharePoint et les feuilles de calcul pour appliquer les configurations des comptes sécurité fiable.
En bref : utilisez mots de passe forts, n'accorder sécurité comptes les autorisations avec des privilèges élevés sur vos serveurs SharePoint, modifier mots de passe souvent (y compris les informations d'identification batterie de serveurs) et n'oubliez pas qu'il y n'a aucune absolue isolation entre les applications Web SharePoint qui utilisent des ressources communes, tout comme il est sans sécurité informatique absolue. En outre, ne modifiez pas le serveur règles de traitement du code, conserver non vérifiés assemblys éloigné vos serveurs et suivre la feuille exigences du compte Windows SharePoint Services de sécurité de votre configuration de compte de sécurité, et vous pourrez à prendre en compte votre environnement SharePoint raisonnablement sécurisé.
Toutefois, si séparation stricte de contenu de site est obligatoire pour votre organisation, je recommande que vous ordinateur hôte les collections de sites correspondant de batteries de serveurs distincts, probablement en séparer forêts Active Directory et environnements de SQL Server.

Pav Cherny est un expert informatique et l'auteur spécialisé dans les technologies Microsoft de collaboration et de communication unifiée. Son compositions incluent les blancs, produit manuels et livres avec une spécialisation sur les opérations INFORMATIQUES et d'administration système. Pav est président de Biblioso Corporation, une entreprise spécialisée dans les services de documentation et de localisation gérés.

Page view tracker