It is possible to put a custom login page up for the Serv-U login screen. When this happens, the page is most likely not displaying the version number. One way that may help identify the version is to visit the Mobile login page at /Web Client/Mobile/MLogin.htm.
Why is this important?
When performing external security scans with tools like Nessus, it may report that the version of Serv-U is incorrect. Finding the version number is important in identifying potential false positives.
Encryption is a reversible process, whereas hashing is one-way only. Data that has been encrypted can be decrypted back to the original value. Data that has been hashed cannot be transformed back to its original value.
Encryption is used to protect sensitive information like Social Security Numbers, credit card numbers or other sensitive information that may need to be accessed at some point.
Hashing is used to create data signatures or comparison only features. For example, user passwords used for login should be hashed because the program doesn’t need to store the actual password. When the user attempts to log in, the system will generate a hash of the supplied password using the same technique as the one stored and compare them. If they match, the passwords are the same. Another example scenario with hashing is with file downloads to verify integrity. The supplier of the file will create a hash of the file on the server so when you download the file you can then generate the hash locally and compare them to make sure the file is correct.
Do you rely on the browser to protect your application from Cross-Site Scripting? Over the years, many of the popular browsers attempted to create these XSS filters to help reduce the risk of the vulnerability. Unfortunately, over the years we have seen a lot of bypasses to these filters. Chrome announced they are removing their XSS Auditor. Hear some of our thoughts on the changes.
Listen to the Episode:
References
https://www.chromium.org/developers/design-documents/xss-auditor
In this episode, James talks about investing in the development teams to increase application security priorities.
For more info go to https://www.developsec.com or follow us on twitter (@developsec).
Join the conversations.. join our slack channel. Email james@developsec.com for an invitation.
DevelopSec provides application security training to add value to your application security program. Contact us today to see how we can help.
[Read more…] about Ep. 114: Investing in People for Better Application Security
Update 8/16/19 – It appears that not long after I published this, Chrome sent an update that now mimics FireFox. In Chrome you now get a new tab that has a URL of “about:blank#blocked”.
When working on a recent test I noticed something pretty interesting when I had found what I thought was a Cross-Site Scripting vulnerability. I have posted previously on the ability to execute XSS when you control the HREF attribute of a link tag. This is done by setting a url to javascript:alert(9);. This might look like:
<a href=”javascript:alert(9);”>Click Me</a>
This is similar to the situation I had. However, when I was testing with FireFox, I found that the alert box was not appearing. Instead, when I clicked the link, it would open a new tab and the URL would be javascript:alert(9);. No Alert box. What gives??
So I could see the payload there, but it wouldn’t execute. I was confused. I decided to load up Chrome and see what happens there. To my surprise, although it is what I originally expected, the alert box was displayed.
It turns out, the link tag wasn’t as simple as the above example. Instead it looked more like this:
<a href=”javascript:alert(9);” target=”_blank” rel=”noopener no referrer”>Click Me</a>
After performing a little more testing, it appears that when the target and red attributes exist, Firefox opens a new tab instead of executing the specified JavaScript. I m not sure if this is a bug in how FireFox handles this scenario or not, but it does highlight an interesting point about differences with browsers.
In the event your testing runs across this same type of scenario, take the time to try different browsers to see if the results change.
A simple error to make when sending an email with sensitive data is to send it to the wrong email address. Imagine you are sending some information to Dave down in accounting. When you fill out the email you start typing Dave and the auto-complete pops up and you select the first one (out of habit). You think you have selected the right Dave, but what if you didn’t? How would you know that you were about to send potentially sensitive information outside of the organization?
Apple Mail and iOS mail has a built in feature to highlight any email address outside of a specified domain. The steps to enable this are a little different based on the desktop vs. an iPad/iPhone. Let’s look at each one.
Desktop
By default, email addresses all appear the same when composing a new message. The image below shows me composing an email with two addresses:
To change this, in the Mail program, go to Preferences…Composing. Under the Addressing: section there is a checkbox for “Mark addresses not ending with“. Check the box and enter your organization’s domain name in the text box. In the image below, I have entered my domain of @jardinesoftware.com.
Now, go back and compose a new message entering in an email address that is in the org and one that is out of it. The email address that is outside of your domain should be highlighted in red. The below image shows my configuration with the same 2 email addresses. Notice that the james@developsec.com address is now listed in red indicating it is external to my organization.
iPhone/iPad
The mail application with the iPhone/iPad also has this capability. To enable this, go into Settings->Mail. Scroll down to the Composing section and click the “Mark Addresses” button (shown below).
On the next screen, enter the email address you don’t want to highlight. In my case, I entered my domain of @jardinesoftware.com. (shown below)
Once the change is stored, go to mail and compose a new message. In my example, I used the same emails as above. Notice that the james@developsec.com email address is now highlighted in red:
Although this is not a fool proof way to stop this type of mistake, it does add in a visual clue that just might catch your attention. Simple changes like this can help reduce your risk of accidentally leaking sensitive information out of your organization.