Please click on below URL, where I have written an article about Update Managed Metadata Field Using SharePoint Designer 2013 Workflow.
Please click on below URL, where I have written an article about SharePoint Permissions Issue : Deny – Add And Customize Pages.
Today, while creating a web application from central administration in SharePoint 2013, I came across an interesting issue, as it was not allowing me to create the web application and was giving the below error, although logged-in as System Account.
Error: “The password supplied with the username <domain> was not correct. Verify that it was entered correctly and try again”.
After this, I contacted the IT Team and came to know that they changed the admin password recently.
Solution : Run the following command in SharePoint 2013 Management Shell (to update the Farm credentials) and it will resolve the issue. Also, make sure that all the services running on the server (services.msc) with the admin account must be updated with the new password.
stsadm –o updatefarmcredentials –userlogin DOMAIN\username –password <password>
OWASP stands for “Open Web Application Security Project”. This article will list all the possible threats or risks which a SharePoint server can have and their preventive measures.
Most of these threats and their preventive measures are available in the internet but here I have tried to put them together in one place.
Risk 1 – Injection
Threat: Injection flaws, such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing unauthorized data.
Prevention: Use SharePoint safe API such as list and libraries, user profile service and business data connectivity, and this will avoid direct connection to SQL databases and LDAP. For custom components, use CAML Queries that will interact with SQL Database as an interpreter and will not be directly queried to the SQL server.
Risk 2 – Cross-Site Scripting (XSS)
Threat: XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation and escaping. XSS allows attackers to execute scripts in the victim’s browser that can hijack user sessions, deface web sites or redirect the user to other malicious sites.
Risk 3 – Broken Authentication and Session Management
Threat: Application functions related to authentication and session management are often not implemented correctly thereby allowing attackers to compromise passwords, keys, session tokens, or exploit other implementation flaws to assume other users’ identities.
Prevention: Use claimed based authentication and default SharePoint Session management to meet the authentication and session management requirements defined in OWASP’s Application Security Verification Standard areas V2 (Authentication) and V3 (Session Management).
Risk 4 – Insecure Direct Object References
Threat: A direct object reference occurs when a reference is exposed to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.
Prevention: For preventing the insecure direct object references, use the SharePoint security permission level as mentioned below:
- Check access. – Each use of a direct object reference from an untrusted source must include an access control check to ensure the user is authorized for the requested object.
Risk 5 – Cross-Site Request Forgery (CSRF)
Threat: A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests that the vulnerable application thinks are legitimate requests from the victim.
Prevention: For preventing the Cross site Request Forgery; follow the steps mentioned below:
- SharePoint will implement Form Digest control on each custom page.
- Send the query (i.e. AllowUnsafeUpdates property will be set to true while updating objects) with every post back or web service request
- Validate the query before acting on the post back or web service request
Risk 7 – Insecure Cryptographic Storage
Threat: Many web applications do not properly protect sensitive data, such as credit cards, SSNs, and authentication credentials, with appropriate encryption or hashing. Attackers may steal or modify such weakly protected data to conduct identity theft, credit card fraud, or other crimes.
Prevention: To prevent Insecure Cryptographic storage, follow the steps mentioned below:
- Identify all sensitive data and encrypt it even when it is stored on a hard drive.
- Ensure that sensitive data cannot be overwritten.
- Keep secrets such as proprietary algorithms, encryption keys even from the administrator.
- Identify sensitive data read into memory, overwrite it with random data and use strong encryption to safeguard it.
Risk 8 – Failure to Restrict URL Access
Threat: Many web applications check URL access rights before rendering protected links and buttons. However, applications need to perform similar access control checks each time these pages are accessed, or attackers will be able to forge URLs to access these hidden pages anyway.
Prevention: To prevent Failure to Restrict URL Access, use appropriate permissions or Access Control settings to disallow anonymous reading. Do not allow read permissions of any sensitive data files to anonymous web visitor user. SharePoint will define/configure the list of file types available for remote reading on the server.
Risk 9 – Insufficient Transport Layer Protection
Threat: Applications frequently fail to authenticate, encrypt, and protect the confidentiality and integrity of sensitive network traffic. When they do, they sometimes support weak algorithms, use expired or invalid certificates, or do not use them correctly.
Prevention: Identify all components and the versions that are being used and consider all the dependencies. Monitor the security of these components in public databases, project mailing lists, and security mailing lists, and keep them up to date. Establish security policies governing component use, such as requiring certain software development practices, passing security tests, and acceptable licenses. Consider adding security wrappers around components to disable unused functionality and/ or secure weak or vulnerable aspects of the component.
Risk 10 – Invalidated Redirects and Forwards
Threat: Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.
Prevention: Avoid usage of redirects and forwards. If the above is used, then do not involve user parameters in calculating the destination. If the destination parameters cannot be avoided, ensure that the supplied value is valid, and authorized for the user.
Recently, I was working in an Office 365 application and wanted to open a modal-pop on the click of an anchor tag from a custom publishing page. The requirement was to show a new item form in the modal pop-up. Although, I worked on this kind of requirement back in SharePoint 2010, but not in Office 365.
SharePoint allows us to hide elements from dialogs, however the CSS class to change such elements has changed from SharePoint 2010 to SharePoint 2013 & Office 365.
So, for example, when we create a custom master page, we usually add custom header and footer to System Master Page. This starts appearing the modal-pop which is not required. So the solution for this problem is:-
- In SharePoint 2010, the CSS class name was “s4-notdlg”. This class needs to be added to an HTML element which we want to hide in the modal-pop.
- In SharePoint 2013 or Office 365, we use the same method, just a different CSS class “ms-dialogHidden”.
- You can add the ms-dialogHidden class to any HTML element in your Master Pages and Page Layouts.
- If you have created separate master pages for Site and System (Option available in site Settings Master Page), then you need to specify this class in System Master Page HTML.
Recently, the client reported that search service application has stopped working in the production server and that they are not getting the search results. When I checked the search service application, under Search Application Topology section, I saw Search Index partition error – a yellow triangle. This definitely meant something is wrong with Index partition in that particular server.
Try the following steps before resetting the search index:-
- Clear the SharePoint Server Cache. Follow this article for detailed steps – Clearing the Configuration Cache
- Restart the ‘SharePoint Server Search 15’ service (services.msc) listed under Services(Local).
- Reset search index (Option available on left in Search Service Application Configuration Page)
The above steps needs to be performed on all the servers in the farm which are running Search service (Not on WFE, as hopefully on WFE Search Service Application is not running).
If Indices are not corrupted and nothing serious has happened to your search, after clearing cache and restarting the service, your Topology should show up just fine with tick marks under all the components. After this, do a full crawl and everything should start working as before.
This worked for me and hope it helps many 🙂
The last option for this issue is – Rebuild or Recreate the whole search service.
I was working in the SharePoint 2013 OOTB “Task List” and developed a custom visual web-part for the “Newform.aspx” and “EditForm.aspx” , having all the control as present in the OOTB forms. (You must be thinking that why I developed custom forms, however this question is out-of-context for this blog). Since I was the site collection administrator, I never faced any issues while adding new items or editing the existing ones.
However, users who are having the “Full Control” or “Contribute” permissions at the task list level , reported that they are facing the following issue which says that they do not have permissions to add new items. On the first thought, it seemed to me a permission issue but I found that if I click on new item from my machine, they were able to open the form from their machines and can add new items in the task list ….Strange enough !!
Error message – “You don’t have Add and Customize Pages permissions required to perform this action”
1. Add a new permission level which only includes “Add and Customize Pages” permission, and then create a new SharePoint group with this permission level.
2. Add the users into the SharePoint group and these users will get the “Add and Customize Pages” permission from the site level (site permission).
If above solution does not work in your system, then give “Full Control” permission to the users at the Site Level.
Hope this blog helps many 🙂