TechShizz | Tech Guides for everything in IT

URL Rewrite rule to remove .php from URLs

URL Rewrite rule to remove .php from URLs 

<rewrite>
  <rules>
    <rule name="Redirect .php extension" stopProcessing="false">
      <match url="^(.*).php$" ignoreCase="true" />
    <conditions logicalGrouping="MatchAny">
      <add input="{URL}" pattern="(.*).php$" ignoreCase="false" />
    </conditions>
      <action type="Redirect" url="{R:1}" redirectType="Permanent" />
    </rule>
    <rule name="hide .php extension" stopProcessing="true">
      <match url="^(.*)$" ignoreCase="true" />
    <conditions>
      <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
      <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
      <add input="{REQUEST_FILENAME}.php" matchType="IsFile" />
    </conditions>
      <action type="Rewrite" url="{R:0}.php" />
    </rule>
  </rules>
</rewrite>



Login CSRF Exploit

Login CSRF is a type of attack where the attacker can force the user to log in to the attacker’s account on a website and thus reveal information about what the user is doing while logged in.

What can happen?

The risk varies depending on the application and is hard to evaluate from a black-box perspective.

PayPal was once vulnerable to login CSRF and the attacker could make a user log in to the attacker’s PayPal account. When the user later on paid for something online, they unknowingly added their credit card to the attacker's account.

Another, less obvious, example is a login CSRF that once existed in Google, which made it possible for the attacker to make the user log in to the attacker’s account and later retrieve all the searches the user had made while logged in.

If public registration for the application exists, the risk of attacks drastically increases as it’s very easy for the attacker to create an account and thus know the credentials for it.

Solution

 <?php
    if (isset($_POST["user"], $_POST["pass"]){
        // Make sure the token from the login form is the same as in the cookie
        if (isset($_POST["CSRFtoken"], $_COOKIE["CSRFtoken"])){
            if ($_POST["CSRFtoken"] == $_COOKIE["CSRFtoken"]){
                // code for checking the user and password
            }
        }
    } else {
        $token = bin2hex(openssl_random_pseudo_bytes(16));
        setcookie("CSRFtoken", $token, time() + 60 * 60 * 24);
        echo '
            <form method="post">
                <input name="user">
                <input name="pass" type="password">
                <input name="CSRFtoken" type="hidden" value="' . $token . '">
                <input type="submit">
            </form>
        '
    }
?>

 

Disable Autodiscover for Office 365 Migration

When migrating to Office 365 the internal outlook users are not able to use autodiscover.

This is because the internal exchange server also uses autodiscover in IIS.

Use this description to remove the internal AutodiscoverVirtualDirectory

Be sure that this is the proper migration plan for you’re organization!

1. Open an elevated command prompt and back-up the IIS configuration (Just in case !):

cd %windir%system32inetsrvappcmd.exe add backup “Before Removing Autodiscover”

2. Open an elevated Exchange Management Shell and retrieve the current autodiscover virtual directory:

Get-AutodiscoverVirtualDirectory | fl Name, Server, InternalUrl, Identity

Copy the Identity value to the clipboard.

3. In the Exchange Management Shell, remove the autodiscover virtual directory:

Remove-AutodiscoverVirtualDirectory -Identity “ALPHAAutodiscover (Default Web Site)”

When you’re identity contains a space, use the quotation marks ”

You will have to confirm by typing a “Y”.

4. Check that the autodiscover virtual directory is gone:

Get-AutodiscoverVirtualDirectory | fl Name, Server, InternalUrl, Identity

This should now return nothing.

5. Now, with Outlook running on a desktop, hold the Ctrl button, right-click on the Outlook icon in the system tray, and select Test E-mail AutoConfiguration. Enter your email address and password and click the Test button. The results should come from the Office 365 server.

DNS | TLSA Records to ensure the validity of SSL certificates

TLSA Records are a new feature which adds an additional layer of security for checking the validity of server certificates. The TLSA record is placed in DNS, which can be queried by a client to verify the SHA hash the domain holds against the certificate a server has presented the client. If the Key matches DNS has "agreed" that the certificate does indeed match. This security protects against the wrongful issuing of certificates by CA's and also the theft of certificates. 

#Add a TLSA DNS Record
Add-DNSServerResourceRecord -CertificateAssociationData 2a8f2d8af0eb123898f74c866ac3fa669054e23c17bc7a95bd0234192dc635d0 -CertificateUsage DomainIssuedCertificate -MatchType Sha256Hash -Selector SubjectPublicKeyInfo -TLSA -ZoneName www.techshizz.com -Name _443._tcp.www

This record combines with DNSSEC provides a robust security system to protect agains man in the middle attacks. Due to the need to DNSSEC, and a provider who offers TLSA, it's going to be a premium service if used on the internet. It does come with server 2016 for internal usage on the corporate infrastructure. 

DNS Time Based Policy

We can configure DNS in server 2016 to DENY, IGNORE or ALLOW the response of DNS requests. Here are the commands required to configure this. 

#Get current server time
Get-Date -DisplayHint Time

#Get current DNS Policies
Get-DnsServerQueryResolutionPolicy -ZoneName demo.com

#Add a new Policy called "Time-Policy" to deny dns requests between 4AM and 11PM.
Add-DnsServerQueryResolutionPolicy -zoneName demo.com -Name "Time-Policy" -Action DENY -TimeOfDay "eq,04:00-23:00" -ProcessingOrder 2

#Check result
Get-DnsServerQueryResolutionPolicy -ZoneName demo.com

#Change Processing order (1 takes precedence)
Set-DnsServerQueryResolutionPolicy -ZoneName demo.com -Name "Time-Policy" -ProcessingOrder 1

#Check result
Get-DnsServerQueryResolutionPolicy -ZoneName demo.com

#Remove the time policy
Remove-DnsServerQueryResolutionPolicy -zoneName demo.com -Name "Time-Policy" -Force

#Re-add the time policy but with IGNORE request instead
Add-DnsServerQueryResolutionPolicy -zoneName demo.com -Name "Time-Policy" -Action IGNORE -TimeOfDay "eq,04:00-23:00" -ProcessingOrder 1

#Remove Time policy again
Remove-DnsServerQueryResolutionPolicy -zoneName hmm.com -Name "Time-Policy" -Force

#Add time policy to DENY between 11PM and Midnight, Order 1
Add-DnsServerQueryResolutionPolicy -zoneName demo.com -Name "Time-Policy" -Action DENY -TimeOfDay "eq,23:00-23:59" -ProcessingOrder 1 

#Check Result
Get-DnsServerQueryResolutionPolicy -ZoneName demo.com

#Change Policy order to 3
Set-DnsServerQueryResolutionPolicy -ZoneName demo.com -Name "Time-Policy" -ProcessingOrder 3

#Check result
Get-DnsServerQueryResolutionPolicy -ZoneName demo.com