A Progammer explores the IT Security field; offering packets of useful information he picks up along the way.
Subscribe

WebGoat

July 13, 2008 By: admin Category: Web App Security

I came across the perfect hands on learning tool that teaches about the common web application vulnerabilities. It’s called WebGoat, an open source J2EE insecure web application created by OSWAP. The purpose of WebGoat is to educate people and organizations on the various risks that are, unfortunately, plaguing our websites. What better way to learn about website hacking than to hack an insecure website with different known exploits. WebGoat has different lessons and some hints that guide the student. It’s a great, fun way to learn web application security. You can be up and running with WebGoat in no time by downloading a zip file that contains the WebGoat code, the Java run time environment and a configured Tomcat 5.5 server. Tomcat is a free Servlet container that implements Java Servlets/Jsp specification. Tomcat also contains a Java webserver. I chose to download the war file and import it into my Java IDE, called Eclipse, so I can analyze the source code. I put my Mac to the challenge; running Eclipse and Tomcat. Using the Mac turned out to be such a pleasure since everything installed and ran smoothly. After installing and configuring everything, I was able to start the Tomcat server from Eclipse and then point my Firefox browser to http://localhost:8080/WebGoat/attack and run the WebGoat application.

Eclipse running WebGoat

Databases are typically used as the back end to web applications. SQL is a query language that is used to interact with the database. SQL Injection is a common web application “vulnerability” that allows an attacker to send data to the back end database. This “string” is then inserted into an SQL query within the application code and executed in the database. If an SQL injection vulnerability exists, then the application may be severely compromised. In some cases an SQL Injection flaw may even allow an attacker to bypass authentication schemes.  In the below WebGoat lesson the student, acting as the attacker, needs to craft some “string” that, when submitted as the “password”, allows access.

 In order to proceed with the hack we will need to alter the HTML or submit the form and intercept the request in order to modify the password field. We can alter the HTML file locally on our computer and then modify the HTML code. We will change the password field to type=’text’ in order for us to see what we type. We will also change the size of the input field (currently it’s only allows 8 characters). A quicker way I found to do this was to use an awesome “Plugin” to Firefox called Firebug that allowed me to modify the HTML on the fly. The other way to proceed with the hack would be to use a tool called WebScarab to manipulate the data passed back to the server. Notice in the screen shot below that you can now see what I typed in the password field instead of asterisks. Also, my password field now allows 30 characters. 

 

Here is the altered HTML in case you can’t see it :

<input type=”text” maxlength=”30” size=”30” name=”password”/>.

Why did the “password” I used admin or ‘1′=’1 allow me to logon and bypass the authentication? We need a little background first on basic authentication for websites. The “password” supplied by the user needs to be verified that. indeed, it is the correct password for this user and whoever is logging on is who they say they are. This is done by querying the database and passing the supplied “password” as a parameter to the query. Here is a simple SQL statement that might be constructed in a web application:

SELECT * FROM user_data WHERE password = ‘?’ and username=’admin’

If the query returns the record from the user_data table then we have a match on the user’s supplied password. If there is no match, then the authentication should fail and a message should be sent back to the user as “Login Failed”.

Now let’s substitute the “password” I supplied into the query:

SELECT * FROM user_data WHERE password = ‘admin’ or ‘1′=’1′ and username=’admin’

The or ‘1′ = ‘1′ makes the entire query true, which returns the user admin record and bypasses the logon scheme. With this crafty string we have successfully exploited the SQL injection vulnerability. SQL injection vulnerabilities are remedied by sanitizing the user supplied input. In the above example, if the server side code had some kind of logic to reject the single quote, our method of attack would have been foiled. In fact, there should be a series of validations for the characters that are white-listed versus those that are not allowed and in this way, an invalid character would be stripped out. The fundamental concept here is that only server side code can thwart attacks such as the SQL injection since, as we demonstrated, the client side code can be easily modified. That’s why it is essential that all input validation is performed on the server side. With some knowledge of these types of attacks and diligence at the development phase, SQL injection vulnerabilities can be avoided.

301 Redirects Explained

June 18, 2008 By: Ron Category: SEO, Uncategorized

Wrote a guest post about “301 redirects“  on my buddy, Shimon Sandler’s blog.   Shimon is very well known in the SEO community and his blog has 1000+ subscribers.  It is a great resource.

Thanks, Shimon, for giving me the opportunity share a post with your readers.

My Yubikey implementation

June 01, 2008 By: Ron Category: Authentication, Web App Security

Today we’re going to continue our discussion on the Yubikey from Yubico. I received mine in the mail a few weeks ago and had the opportunity to play around with the device a bit. Many people were attracted to the Yubikey because of it’s cool, tiny keyboard - so they ordered them. When it arrived they plugged it into their computers and touched the green surface which then spits out a 44 character encrypted one time password. That’s all nice and very cool but now what? How can this very innovative security token that is a tiny USB keyboard be put to good use? I, therefore, devised a way to prove that this cool token can really deliver. My plan was to customize this blog’s “admin logon” and incorporate the Yubikey authentication as an added layer of security.

Good news, Yubikey authentication is open source! This means that developers are able write code both on the client side as well as the server side to leverage the Yubikey in their own environments. There are not too many options for do-it-yourself hardware authentication solutions! Yubico offers sample code in a variety of languages that can help you get going. You can also authenticate against Yubico’s authentication server, hosted by them. This would come in handy for companies that plan on implementing their own server authentication, however, are not there yet and would like to test their client side code. In my case I decided to authenticate against Yubico, since it’s simpler and quicker. There is a downside to this approach that is worth mentioning. If I wanted to log onto my blog’s “admin panel” and for some reason the Yubico authentication server was down, I would be locked out of my blog’s admin panel.

This blog uses Wordpress, the popular open source PHP blogging software. Modifying the admin logic to include the Yubikey as a 2nd level of authentication was very easy. I utilized the code written for PHP. First, I dropped in the Yubico class on my server. I then added in some code to the wp-login.php file.

Here is the function that calls the Auth_Yubico class:

function verifyYubikey ($token) {
global $error;

$yubi = &new Auth_Yubico(’77′,’5dFRPaFvjBvwiiB023ZWu4Qb++U’);
$auth = $yubi->verify($token);
if (PEAR::isError($auth)) {
$yub_error = $auth->getMessage();
$error = __(’<strong>ERROR</strong>: ‘. $yub_error);
return false;
} else {
return true;
}

}

Here is where I modified the logic for logging on in the wp-login.php file.

if (verifyYubikey($user_yub) && wp_login($user_login, $user_pass, $using_cookie)) {

I verify the yubikey string prior to verifying my static password so people can try it out by putting in a password and see what errors are returned back from Yubico’s authentication server; more on that shortly…

So, how does the Yubikey work? We talked about asymmetric encryption in a prior post. Each Yubikey contains a unique private key that encrypts some data, turning it into the encrypted OTP (One Time Password). The Yubikey uses a conversion scheme to ASCII, which they call mod-hex. The 44 character blob is made up of 12 characters plus the 32 character OTP. The first 12 characters never change; they are your Yubikey’s unique id. So you have the 48 bits plus an AES encrypted 128 bits sent over to the authentication provider (in my case, the Yubico server). Yubico then does a lookup with my unique 12 characters and pulls the “public” key to do the decryption. Now, if the authentication side is able to decrypt this blog then you are successfully authenticated. After decryption you have 128 bits of cipher text. Besides containing your unique id, the cipher text also contains some additional useful information about how your Yubikey has just been used. For example, the time-stamp of when the OTP was generated is included, as well as a session “use counter” showing how many times you generated an OTP. This information can be used to thwart some sneaky phishing attacks. Another thing to note is that your secret AES key in the Yubikey is never able to be read out; nothing you can do to the device can force it to give you it’s secret key. All in all, this hardware solution is extremely secure.

Below are two Yubikey passcodes generated from my Yubikey that I used to authenticate myself when creating this post. I highlighted the first 12 characters, my unique serial number indentifying my Yubikey. You can copy and paste the string in the Yubikey field on my admin page and then type in anything for the static password (logic for verifying Yubikey is done prior to the static password as you can see in the PHP code above).

jdteklknnhcffbfgjebejhbbgnrtrevingnldlctiulj
jdteklknnhcfnfidtedkcelbrkvngurddrclghnidgfh

To make sure the responses come from Yubico, they offer you the ability to create an id with a shared key. When you authenticate, there is an extra field returned to which you can apply a signature algorithm. To apply this algorithm you use your shared key to validate that the response actually came from Yubico. In the code of the “verify method” above I included my id of 77 and the shared key that was assigned to me. I just tried changing the shared key by adding a “1″ to the end of that string and wasn’t alerted that my signature algorithm failed; which it should have done. Perhaps I’m doing something incorrectly; feel free to comment. I’d like to say thank you to Simon from Yubico who was responsive to the questions I posed. Yubico also set up a forum where you can learn more about Yubikey.

Compression on the job

May 26, 2008 By: Ron Category: On the Job

Worked on an interesting assignment at work the other week. A little background first. TIBCO is a middle-ware solution used frequently in the financial industry. Tibco allows legacy applications to talk or communicate with each other. For example, a process in C++ can publish a TIBCO message that can be picked up and processed by a Java process and vise-versa. TIBCO is set up to run throughout the firm, across many different applications. TIBCO can be set to run in two modes; ‘reliable’ and ‘certified’ mode. Reliable messaging is not concerned with the receiving party actually receiving the message, it’s a publish and forget. If the recipient picks up the message that was sent, fine. If the recipient didn’t pick up, also fine. That is not the publishing process’ concern. Certified messaging, on the other hand, makes sure the receiving process or processes (multiple processes listening) actually get the message. If the receiver didn’t get the message because the process crashed, messages will be queued up so that when the process comes back up, the messages in the queue will be published out again.

The main process that runs on Unix talks to the Front-End (FE) trading system in reliable mode. The messages that are published to the FE are order acknowledgements, executions, tickets, amongst other types of messages. The FE processes these message in real-time. You can imagine all these messages being published out to 1000+ trading FE’s. So it’s possible that all these processes running might overload the network, especially in high volume trading times. We, therefore, needed a way to ease the amount of data sent over the wire to all these FE’s. I decided to try good old compression similar to ZIP and GZIP. I implemented a solution in JAVA that compressed the Java String message before it was published out over TIBCO to the FE. The FE needed coding modifications for this solution, as well, to handle the compressed messages and perform the decompression on the fly. I also made sure that this functionality can be turned off at run-time, just in case something unforeseen happened and we need to revert back to sending messages uncompressed.

Data compression reduces the size of data by using a compression scheme. There are many different types of compression algorithms that are used differently for certain types of files. The table below shows the compression rates of a few sample messages that were compressed using “on the fly” compression. Notice that the bigger the message, the better compression rate you will get. The reason is that “on the fly” compression uses a substitution scheme, so the more repetitive the text, the better compression rate you will get.

RSA 2008 and Yubikey

May 02, 2008 By: Ron Category: Authentication

On Securitynow podcast #141 Steve Gibson talks about his experience at RSA Conference 2008 a few weeks back. The RSA Conference is the largest of it’s kind in the world focusing on information security. I mentioned to a friend that I’m going to be at the RSA Conference in 2009 and I’m going to leave the kids somewhere and bring my wife. Ok, ok - that’s pushing it.Steve gave out a url which takes you to RSA conference Keynote speakers so you can watch at your leisure. There is one really fascinating keynote address by Jeff Hawkins about brains and computers (AI) that is worth watching.  Jeff Hawkins co-authored a book called, “About Intelligence”.

At RSA Steve stumbled on a really cool new product called the Yubikey from a Swedish company called Yubico. The Yubikey is a very small USB authentication device. You plug it in to your computer’s USB port and then go to, say, a website that was all set up to support Yubikey. Touch the device and it will spit out a really long one time password sequence. If you have the the device that is associated with you (based on the devices serial number I would guess) then you are authenticated. In authentication speak this form of authentication would be something you have, while your static password is something you know. The really cool thing about this device is that the Yubikey contains a tiny keyboard so you don’t have hardware compatibility issues. I need to learn more in order to fully explain how this works. What better way to learn about the product than to implement it. We talked about securing my blog’s “Admin panel” in a previous post. I have username/password and for a 2nd factor authentication I can use the yubikey. I sent the company an email the other day expressing my interest in the product. I got a response back from the CEO.

“Thanks for your interest in Yubico….Since Steve Gibson sent his latest SecurityNow! podcast interest in our product has greatly exceeded our expectations. We are working hard to catch up with demand and sincerely apologize to all of you who are still waiting to receive shipments from us. We expect to be caught up within the next two weeks. ……. “

I’m sure the CEO is happy she met Steve at RSA. I’ll keep you updated on my progress in implementing the Yubikey on my blog’s “admin panel”. We also need to discuss “openID” since the yubikey is openID compliant. In short you can use your Yubikey when logging onto sites that support openID for an added level of security. Until next time..

***** Follow up ******

New post on my Yubico Impementation.

.htaccess file

April 06, 2008 By: Ron Category: Web App Security

I’ve been reading and learning about web application security lately. As a programmer with experience in web redevelopment, I thought web application security would be the perfect place for me to get my security fix. I’m finding it very interesting. I decided that a good place to start learning was with my blog application; how can I better lock down this blog. My blog uses the very popular open-source blogging solution called Wordpress. Recently I found a posting on Matt Cutt’s blog on some things you can do to secure your Wordpress blog. Let’s discuss one his simple recommendations I implemented.The first thing I did was create a .hatches file in my “wp-admin” directory.

AuthName “Access Control”
AuthType Basic
order deny,allow deny from all
# whitelist home IP address
allow from 71.172.62.228

The .htaccess files are also called “distributed configuration files” which allow you to restrict access to a particular resource in a web application. If you have access to the main configuration files (usually httd.conf) on the server it is better to make theseconfiguration changes there, since modifying the .htaccess file may cause your application to take a performance hit. My blog is hosted in a shared environment and therefore, I don’t have access to the main configuration file. My .htaccess file essentially blocks everyone (all IP’s) from accessing the www.itsecpackets.com/blog/wp-admin directory unless the TCP connection is made from the IP specified, which is my home IP address. When I access the admin page as the admin, I will still need to enter my username/password. This solution gives me another layer of security. Now keep in mind, with security comes a loss of convenience. I will not be able to logon to my Wordpress admin panel from work (unless I add the IP address). The same applies if I’m at a friend’s house. There are always trade-offs when it comes to security - always.

Apple’s Big Announcement

March 20, 2008 By: Ron Category: Apple

I’m a big Apple fan. There is big Apple news that I feel the need to share! Apple announced at their much publicized event on March 6th that they will be allowing developers to write programs for the iPhone and iTouch devices. The Software Development Kit or SDK is available to download from the Apple site. You will need a MAC running their new Leopard OS to write programs. People, this is really big!!! I was totally blown away watching the event the other evening. Apple invited 5 different companies spanning diverse industries, from games to medical software to present their programs at the event. The developers had 2 weeks to program something new for the event. Some had never written software on the MAC before. The companies themselves were quite surprised to see what they were able to accomplish in such short period of time. I think this move by Apple to invite third-party developers to program using the Apple SDK will propel the IPHONE into new dimensions. This is a huge accomplishment. It is simply a revolutionary device, a hand-held mobile computer that is always connected. In my opinion, Apple is reinventing the personal computer.

Apple will be the gatekeeper for all these programs. The only way you’ll be able to install these programs on your iPhone is through the "App Store" on iTunes which will be accessible using wireless, as well. Developers will name the price for the programs they write. Apple will take 30% off the top and the developer will get 70% of the set price. Apple will be hosting the application, distributing and marketing your application. Developers will need to adhere to Apple’s rules when writing programs. No porn, no malicious software, no illegal or privacy software will be allowed. It has yet to be seen whether Apple will allow applications that might compete with their own applications. If Amazon wants to create an MP3 download service, would Apple allow it to compete with their own WIFI iTunes store application? Or let’s say Sun wants to create a JVM to allow Java programmers to write code; will that be allowed? Lots of questions surface but we’ll have to wait until the end of June to see what happens.

So, being a developer, I absolutely had to download the SDK. I downloaded the "Hello World" sample application and opened up the source code in Xcode ( Apple’s IDE). With a click of a button I had the program running on the IPHONE simulator. I wish I had more time to play with this! As we speak, developers all over the world are writing programs. Bloomberg reported today that the SDK had 100,000 downloads of programs in less than a week. Another interesting point that Adam from the Maccast brought up is, what he calls, the halo effect for developers. He thinks that once developers start creating iPhone programs, they will love the experience and will, thus, want to start developing for MAC products.

Another very cool iPhone feature that is specifically geared to the gaming companies is the accelerometer. The accelerometer detects when the device is turned or moved and the display is viewed differently as directed by the movement. You may view pictures or video in landscape mode or look at a webpage in wide screen. Developers can take advantage and code for how the device is moved in the 3D space. This is particularly applicable to game developers. At the demo, I was blown away by the graphics/accelerometer use in the game called "Spore", developed by EA and a monkey game by Sega. To control the game you move and tilt the iPhone; very cool stuff indeed

Plausible Deniability

March 12, 2008 By: Ron Category: Encryption, Privacy

There is an interesting concept that surfaces sometimes in business, politics or espionage called “Plausible deniability”.  It involves the creation of chains of command that are loose enough to untie when the need arises.  If high ranking officials or politicians become aware of disreputable or questionable activities, they may claim, using “Plausible deniability”, that there is no  way of proving they had any knowledge of such activities.  They can simply deny it, and since there is no direct connection to these high ranking officials, there can be no hard evidence linking themselves to the questionable activity or to the knowledge thereof.  The Plausible deniability concept is also applicable in technology, as you”ll see.

There is this great open-source encryption  software that you can install for free called Truecrypt.  Since most people have bank statements or other sensitive files stored on their computers, this program is for everyone.   You can easily set up what they call an “encrypted volume”.  What is that?  It looks just like any of your letter drives on your computer, but it is really a container of all your encrypted documents.  You can drag your sensitive files right into this new drive and use it just like any other drive, ie: drive F: on your computer.  Truecrypt performs “on the fly” encryption which means that your file is encrypted and decrypted in memory as you use work with it.    When you are done updating a file, it is always written back to the volume encrypted so you never have to worry!

When you mount a Truecrypt volume you need to enter your password and when the computer shuts down down the volume is then unmounted.  If you look at the file that is used to mount these encrypted volumes you’ll see random bits of data.  There is absolutely no way to get any information about your data stored on the encrypted file; it’s just random noise.  To give you an idea of how safe your data is, Truecrypt writes on their website:

“The only way to recover your files is to try to “crack” the password or the key, but it could take thousands or millions of years depending on the length and quality of the password/keyfiles, on software/hardware efficiency, and other factors.”

These guys really covered everything, so it is a highly secure system.  Truecrypt volumes are extremely easy to set up and their website is a great resource for how to get started and learn more about how this technology works.

Back to Pluasible deniability.  Let’s say that I created an encrypted volume and put some very sensitive files in my encrypted container, all is good and my data is quite safe.  Now let’s suppose that some evil  person gains access to your  computer and forces you to give over your secret files he thinks you have.  He knows that you’re smart and that you must have encrypted your sensitive data.  You have no choice but to give him your password and he then can take your files!  To get around this scenario, Truecrypt allows you to create a hidden volume.  A hidden volume is an encrypted volume within another encrypted volume, each having different passwords.  Now, in the case of the evil person, you can say to him “here are my secret files” and give up the password to the outer volume.  The files you “gave” him in the outer volume are not really your sensitive files.  The inner volume contains the truly secret files.  When you open up the outer volume there is absolutely no way of knowing that there is a hidden volume inside.  You have successfully invoked “Plausible deniability” in the sense that your adversary does not know anything other than that outer volume exists and you do not “have” any secret files the adversary wants.  The direct link was severed and you can deny any knowledge of those files.

In a future post we”ll talk about whole disk encryption a new feature of truecrypt. This solution is perfect for laptops or even desktops that contain sensitve data.

Hamachi, quick and easy VPN

February 24, 2008 By: Ron Category: VPN

Before we had the Apple’s OS X Tiger there was no way to do screen sharing across the Internet.  My grandfather, who lives in Michigan, had just bought a new  Mac.  I wasn’t going to fly out there but he desperately needed some help showing him how to use his Mac.  I, therefore, needed a way to control his computer remotely.  In most households there is a router with at least one, if not multiple computers, sharing the Internet connection.  This is, essentially, a network setup.  We can share printers, share files between computers, amongst other things. With my grandfather, what I really needed was to be on his network; this way I could easily connect to his computer with his IP address. Now you’re going to ask, why don’t you just get his IP address and connect over the Internet without being on his network?  Good question!  Remember, his IP address is not the IP address of his computer, it’s the IP address of his router.  The truth is it can be done, though we would need to configure his NAT router, punching some holes to allow certain traffic to flow through the router to his MAC.  This type of configuration is complex and besides, there is no way my grandfather is going to be able to do this.  What we need here is a VPN (Virtual Private Network) and Hamachi is just the solution, plus it’s free!

A VPN is a network that uses the public infrastructure, such as the Internet to provide users with secure access to their organization’s network.  Very often you will find corporate VPN’s. What that means is an employee who is out on the road or working from home and needs access to the corporate network, is able to gain access via the corporate VPN and thus, work off-site.  Since the VPN’s operate over the Internet, an insecure medium, there is a real need for bullet proof security using extremely robust encryption protocols. 

I downloaded and installed HamachiX for the MAC.  I was able to easily set up a network then I gave the network a name and a password.  Now that I have a VPN setup on my end,  I had my grandfather install HamachiX on his MAC.   He joined the network I created by using the name I gave it and the password.  I was then able to see him logged in.  I then had him configure his MAC to run the remote desktop service and also have his firewall accept the VNC client connection.  VNC is remote control software which allows you to view and fully interact with a computer desktop.  I fired it up on my MAC.  I make the connection using the IP address that Hamachi gave my grandfather’s computer and the port the service was running on; voila! His screen appears in the window.  I am now able to control his computer.  Hamachi is “zero configuration”, meaning I did not have to re-configure my grandfather’s router.  It was like his computer was in my house on my network.  I was able to telnet to his computer and I could even set up to print to his printer in Michigan if I wanted to. 

 If you’re in a hotel away from home using the hotel’s insecure wireless, Hamachi would be a great solution to securely connect to your home computer and access files, or even browse the net off your home computer.  It’s really an intelligent solution for the small business or home user who needs to access computers across the net in a secure mode.

SPF

February 13, 2008 By: Ron Category: Spam

There is a very neat open standard that is helping solve the ubiquitous SPAM issue. If you have an email account you must know what SPAM is. SPF stands for “Sender Policy Framework” and is an extension to the SMTP standard. We need to understand SMTP before we delve into SPF.Most Internet technologies are based on the concept of a client/server relationship. Sending email is no different. When you browse on the Internet you have a browser (client) and the web-server (server) that serves you the page. With email you usually have an email client that is configured to talk to an SMTP server for sending email. For receiving email your client can talk to a POP3 server or an IMAP server. When you compose an email there must be at least one recipient. Let’s say you have an account with Verizon (your ISP) and you are sending email to a Gmail recipient. You write your email and click “send” and the email is sent to Verizon’s SMTP server, the server that handles all outgoing email. The SMTP server then looks at the recipient and sees that the domain (after the @ ) is intended for someone over at Gmail. It then makes a DNS request to find the IP associated with it’s counterpart over at GMAIL, which is Gmail’s SMTP server. Verizon SMTP server sends the email off to Gmail’s SMTP server. Gmail’s SMTP server will then see that the recipient has a Gmail account and it will drop the email into that person’s mailbox. Now, if you open up an email and look at the headers, there will be a series of “received” headers that will show you the path that the email took. This path looks like a stack, with the first one being the last destination. The “Received” header at the top is actually the last SMTP server that received the email and the bottom “received” header is the first SMTP server that received the email. Every SMTP server that receives that email will stamp a received header onto the email with the IP address of the client or server they received the email from. The received header information becomes essential for SPF, as you’ll see.

The difficult part with this approach is that the FROM address can be spoofed. So my address rongoodbin@veizon.net can be substituted with bill@microsoft.com easily. Nearly all SPAM is sent by fake people who hijack peoples’ real email address’. Spammers like to use addresses with domains that have credence on the Internet. You are more likely to read a piece of spam sent from john.goldstone@ibm.com than some other email like girly1234@aol.com. This type of thievery undermines the credibility of email, which is an unfortunate consequence, and like other Internet technologies security, it wasn’t even a thought at design time.

SPF was created to help remedy this problem and try to help restore the confidence in email integrity. We need some way to authenticate the sender’s email address and not just blindly accept what was supplied as the true sender. Here’s how it works. We talked earlier about the email hopping as it goes from one server to the next en-route to it’s destination. As it travels, the server will stamp the email with the IP address of where it came from. Say there is an email sent to someuser@gmail.com from someone claiming to be rongoodbin@verizon.net. Now, if Gmail is configured to operate with SPF, Gmail will then make a DNS request for the SPF record that verizon.net has configured and stored. This SPF record from Verizon tells Gmail what the IP range this email should be coming from. Gmail then checks the IP address from the received header on the email. Remember, an IP address can’t be spoofed, as we saw with my
question on security now post. If the IP address checks out ok - meaning that it’s in the range allowed by the SPF record, then we know this email was actually sent by Verizon’s SMTP server and not someone from a different SMTP server out in Russia sending mail on behalf of a verizon.net user. Now this valid email will be forwarded to the recipient’s mailbox. If it turns out to be invalid, then the email is discarded. SPF, along with other technologies, is definitely a step in the right direction in the constant fight against SPAM.