Assessing Security Standards in Popular Iranian Websites

Abstract

The security of websites under the control of governmental agencies, ministries and bodies is a significant issue in most countries around the world as they usually do not meet minimum standards requirements. The digital security of governmental websites is important as they usually host sensitive information such as political and military secrets, health records of their citizens, etc., and they are always interesting targets for state-backed hackers or cyber criminals.

Certfa Lab has analysed more than 120 Iranian’s state websites showing they are not secure and in some cases they do not implement the basic security standard that causes a website to become a security hazard.

Our assessment shows Atomic Energy Organization of Iran (AEOI)¹ is the only website that has applied basic security standards on their website. As a result, more than 60% of the Iranian state websites are not secure - according to the OWASP standards - and they do not follow the basic standard in terms of implementation of general protocols and configuration for HTTP response.

Assessment Note

Our goal for sharing this analysis is not to explain the function of OWASP and other standards, as other educational sources have spent enough time explaining them in detail. The aim of this assessment is to raise awareness of the people who follow these standards in Iran, and to encourage online platforms to implement security standards. It also refers to the security status of the Iranian state websites and their unsafe conditions.

We have published another report about Assessing Security Standards in Popular Iranian Websites that is available here.

Assessment method

For this assessment, we chose 125 main websites of the Iranian state, based on available related links on the websites of The General Secretariat of the Council of the Government, ICT Ministry, and The Office of the Supreme Leader.²

Also, same as our previous assessment report, we only assessed the “implementation of general protocols” and “websites configuration for HTTP response” by using these tools:

HTTP Observatory, created by Mozilla Foundation
Hardenize, created by Hardenize team

Assessed Standards and Criteria

In order to achieve reliable results, these criteria have been divided into two sections based on function and importance:

1- Basic security settings that all websites are required to implement:

2- Hardening security configuration that businesses and popular websites are recommended to implement:

Due to legal restrictions for advanced security tests, which must be approved by the owners of websites, we only assessed basic standards which all can be categorized as the general features of websites, but according to legal restrictions and our policies, we will not publish all details in this report. Additionally as a reminder, we did not penetration test or test bypass methods of configurations.

Results of reviews

In this section, for a brief definition of standards and types of tests, we have mentioned helpful descriptions from Mozilla Infosec and Hardenize Website at below of each chart.

Note: Websites may continue to listen on port 80 (HTTP) so that users do not get connection errors when typing a URL into their address bar, as browsers currently connect via HTTP for their initial request. Sites that listen on port 80 should only redirect to the same resource on HTTPS.

Note: All cookies should be created such that their access is as limited as possible. This can help minimize damage from cross-site scripting (XSS) vulnerabilities, as these cookies often contain session identifiers or other sensitive information.

Note: Access-Control-Allow-Origin is an HTTP header that defines which foreign origins are allowed to access the content of pages on your domain via scripts using methods such as XMLHttpRequest. crossdomain.xml and clientaccesspolicy.xml provide similar functionality, but for Flash and Silverlight-based applications, respectively. These should not be present unless specifically needed.

Note: X-Content-Type-Options is a header supported by Internet Explorer, Chrome and Firefox 50+ that tells it not to load scripts and stylesheets unless the server indicates the correct MIME type. Without this header, these browsers can incorrectly detect files as scripts and stylesheets, leading to XSS attacks. As such, all sites must set the X-Content-Type-Options header and the appropriate MIME types for files that they serve.

Note: X-Frame-Options is an HTTP header that allows sites control over how your site may be framed within an iframe. Clickjacking is a practical attack that allows malicious sites to trick users into clicking links on your site even though they may appear to not be on your site at all. As such, the use of the X-Frame-Options header is mandatory for all new websites, and all existing websites are expected to add support for X-Frame-Options as soon as possible.

Note: X-XSS-Protection is a feature of Internet Explorer and Chrome that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks. Although these protections are largely unnecessary in modern browsers when sites implement a strong Content Security Policy that disables the use of inline JavaScript (‘unsafe-inline’), they can still provide protections for users of older web browsers that don’t yet support CSP.

Note: Content Security Policy (CSP) is an HTTP header that allows site operators fine-grained control over where resources on their site can be loaded from. The use of this header is the best method to prevent cross-site scripting (XSS) vulnerabilities. Due to the difficulty in retrofitting CSP into existing websites, CSP is mandatory for all new websites and is strongly recommended for all existing high-risk sites.

Note: Subresource integrity is a recent W3C standard that protects against attackers modifying the contents of JavaScript libraries hosted on content delivery networks (CDNs) in order to create vulnerabilities in all websites that make use of that hosted library. For example, JavaScript code on jquery.org that is loaded from mozilla.org has access to the entire contents of everything of mozilla.org. If this resource was successfully attacked, it could modify download links, deface the site, steal credentials, cause denial-of-service attacks, and more.

Note: When a user navigates to a site via a hyperlink or a website loads an external resource, browsers inform the destination site of the origin of the requests through the use of the HTTP Referer (sic) header. Although this can be useful for a variety of purposes, it can also place the privacy of users at risk. HTTP Referrer Policy allows sites to have fine-grained control over how and when browsers transmit the HTTP Referer header.

Note: HTTP Strict Transport Security (HSTS) is an HTTP header that notifies user agents to only connect to a given site over HTTPS, even if the scheme chosen was HTTP. Browsers that have had HSTS set for a given site will transparently upgrade all requests to HTTPS. HSTS also tells the browser to treat TLS and certificate-related errors more strictly by disabling the ability for users to bypass the error page.

Note: DNSSEC is an extension of the DNS protocol that provides cryptographic assurance of the authenticity and integrity of responses; it’s intended as a defense against network attackers who are able to manipulate DNS to redirect their victims to servers of their choice. DNSSEC is controversial, with the industry split largely between those who think it’s essential and those who believe that it’s problematic and unnecessary.

Note: CAA (RFC 6844) is a new standard that allows domain name owners to restrict which CAs are allowed to issue certificates for their domains. This can help to reduce the chance of misissuance, either accidentally or maliciously. In September 2017, CAA became mandatory for CAs to implement.

Note: Expect-CT is a response HTTP header that web sites can use to monitor problems related to their Certificate Transparency (CT) compliance. Additionally, they can also instruct browsers to reject any certificates in their name that are are not CT-compliant.

Note: Transport Layer Security (TLS) is the most widely used encryption protocol on the Internet. In combination with valid certificates, servers can establish trusted communication channels even with users who have never visited them before. Network attackers can’t uncover what is being communicated, even when they can see all the traffic.

Note: Sender Policy Framework (SPF) is a protocol that allows domain name owners to control which internet hosts are allowed to send email on their behalf. This simple mechanism can be used to reduce the effect of email spoofing and cut down on spam.

Note: Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling.

Note: DNS-based Authentication of Named Entities (DANE) is a bridge between DNSSEC and TLS. In one possible scenario, DANE can be used for public key pinning, building on an existing publicly-trusted certificate. In another approach, it can be used to completely bypass the CA ecosystem and establish trust using DNSSEC alone.

Note: SMTP Mail Transfer Agent Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections, and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate.

Note: SMTP TLS Reporting (RFC 8460), or TLS-RPT for short, describes a reporting mechanism and format by which systems sending email can share statistics and specific information about potential failures with recipient domains. Recipient domains can then use this information to both detect potential attacks and diagnose unintentional misconfigurations. TLS-RPT can be used with DANE or MTA-STS.

Useful Resources and Tools

Footnotes:

Atomic Energy Organization of Iran https://www.aeoi.org.ir ↩︎
The General Secretariat of the Council of the Government http://dolat.ir/
ICT Ministry https://www.ict.gov.ir/
The Office of the Supreme Leader https://www.leader.ir/ ↩︎

Assessing Security Standards in Iranian State Websites

Web Security - Part 02