• Skip to main content
  • Skip to primary sidebar
  • Skip to footer

DevelopSec

  • Home
  • Podcast
  • Blog
  • Resources
  • About
  • Schedule a Call

AppSec

March 19, 2022 by James Jardine Leave a Comment

Is encoding really encoding if it is escaping?

The title might be confusing, let’s see if we can clear it up.

I saw an article the other day that was giving a comparison between encoding, encryption and hashing. There was a statement made that basically said:

Encoding has no security purpose.

I thought this was interesting because when training on security topics we mention encoding for specific use cases. For example, when we discuss Cross-Site Scripting, the answer is output encoding.

I want to clarify that I agree with the statement in the article in that encoding does not provide any type of protections regarding confidentiality or anything like that. There is no data protection there. It does start me thinkng about encoding vs. escaping.

In the example above, regarding XSS, we really are talking about escaping, right? For SQL Injection we would say to escape the data, not encode it. For XSS we are trying to achieve the same goal: Ensure that control characters are not interpreted, but read as data.

The difference is that for SQL we would escape something like a single quote (‘) with two single quotes (”). This tells the Interpreter to treat the single quote as data (like O’Reilly) instead of treating it like a delimiter around data.

However, in the browser we typically encode characters rather than escape them. Instead of returning a (<) character, I would return (&lt;). This tells the browser to display a (<) character on the page rather than treat it as the beginning of an HTML tag.

This leads to some confusion when you are following the rules of the interpreter that uses encoding to escape.

When I teach classes I always use the different terminology when I cover these vulnerabilities. SQL Injection uses escaping. XSS is focused on encoding. In the end, the goal is escaping even though one uses encoding.

This becomes confusing when you want to discuss encoding at a pure level as it tends to have a different meaning depending on the context that you use it.

While encoding and escaping are technically different things, their terms are used almost as one when it comes to things like cross-site scripting. In that context, the encoding actually does provide a security purpose even though it is based on the interpreter the data is being sent to.

Security can be confusing at times. If you have questions or thoughts about application security, I would love to have a conversation around them. Feel free to reach out to me. Let me know what struggles you have when it comes to appsec.

Filed Under: General Tagged With: application security, AppSec, cross-site scripting, developer training, training, vulnerability, xss

January 3, 2022 by James Jardine Leave a Comment

How Can I Find The Version of Serv-U FTP on Custom Branded Login?

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.

Filed Under: Questions Tagged With: AppSec, pen test, pen testing, penetration testing, security, security awareness, Serv-U, training

December 20, 2021 by James Jardine Leave a Comment

What is the difference between encryption and hashing?

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.

Filed Under: Questions Tagged With: application security, AppSec, crypto, encryption, hashing, questions, secure development, security awareness, security testing, training

December 19, 2021 by James Jardine Leave a Comment

Ep. 118: Log4J Sparking Thought on Vulnerable Components

Log4J has been the talk of the town recently and everyone is focused on the technical details of the specific vulnerabilities found. In this episode, James talks about the overarching ideas around dealing with vulnerable components. Are you vulnerable? If so, what needs to be done?

Listen to the Episode:

For more info go to https://www.developsec.com or follow us on twitter (@developsec).

[Read more…] about Ep. 118: Log4J Sparking Thought on Vulnerable Components

Filed Under: Podcast Tagged With: application security, application security program, AppSec, leadership, owasp, podcast, secure development, security training, training, vulnerable component

December 15, 2021 by James Jardine Leave a Comment

Log4J – Reflection and Progression

Open any social media platform or pull up any mainstream media and undoubtably, you have seen many posts/articles talking about the log4j vulnerability. If you haven’t seen this, here is a quick link to catch up https://snyk.io/blog/log4j-rce-log4shell-vulnerability-cve-2021-4428/.

This post is not going to be about log4j, nor is it going to go into any of the details the thousands of others articles out there would go through. Instead, I want to discuss this at a higher level. Log4j is just an example of the risks of using 3rd party components and should be pushing a broader discussion within your organization and team.

The use of Vulnerable and Outdated Components – https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/ – Is ranked 6th on the OWASP Top 10.

If you have already started dealing with this (and if you haven’t, you should be), you have probably had similar questions as others out there. The biggest question probably every organization and security team had was “Am I vulnerable?”.

This is a great question, but how easy is it to answer?

Am I vulnerable?

If you had one application with minimal dependencies, maybe this is a quick answer. Maybe it is not a quick answer. As a developer, you may just have responsibility for your application. You also might be able to quickly answer to what version of what dependencies exist in your application. Well, maybe high level dependencies.

As an organization, it may not just be custom in-house applications that we are worried about. What about other applications you use within your organization that could be vulnerable to this. Are you using Software as a Service that could be vulnerable? As we start to pull on these different strings, they start to get tangled together.

[Read more…] about Log4J – Reflection and Progression

Filed Under: General, Take-Aways Tagged With: 3rd party component, application security, AppSec, awareness, components, exploit, log4j, owasp, secure code, training, vulnerability, vulnerable component

May 29, 2020 by James Jardine Leave a Comment

Proxying localhost on FireFox

When you think of application security testing, one of the most common tools is a web proxy. Whether it is Burp Suite from Portswigger, ZAP from OWASP, Fiddler, or Charles Proxy, a proxy is heavily used. From time to time, you may find yourself testing a locally running application. Outside of some test labs or local development, this isn’t really that common. But if you do find yourself testing a site on localhost, you may run into a roadblock in your browser. If you are using a recent version of FireFox, when you go into your preferences screen and click on the Network Settings “Settings” button, you might notice the following image:

DenyProxy

When configuring your proxy, there is a box to list exceptions to not proxy traffic for. In the old days, localhost used to be pre-populated in this box. However, that is not the case anymore. Instead, localhost is explicitly blocked from being proxied. You can see this in the highlighted area of the image above.

So how do you you proxy your localhost application? There are a few ways to handle this.

You could set up your hosts file to give a different name to your local website. In this case, you would access the application using your defined hostname, rather than “localhost”.

Another way to get around this would be to modify the about:config of Firefox and update the network.proxy.allow_hijacking_localhost property true as shown in the following image:

AllowHijacking

Once this change is made, it will update the network settings screen to no longer block localhost from proxying. The following image shows that this statement is no longer there:

AllowProxy

Filed Under: General Tagged With: application security, AppSec, pen test, pen testing, pentesting, qa, secure development, security testing

  • Go to page 1
  • Go to page 2
  • Go to page 3
  • Interim pages omitted …
  • Go to page 8
  • Go to Next Page »

Primary Sidebar

Contact Us:

Contact us today to see how we can help.
Contact Us

Footer

Company Profile

Are you tackling the challenge to integrate security into the development process? Application security can be a complex task and often … Read More... about Home

Resources

Podcasts
DevelopSec
Down the Security Rabbithole (#DTSR)

Blogs
DevelopSec
Jardine Software

Engage With Us

  • Email
  • GitHub
  • Twitter
  • YouTube

Contact Us

DevelopSec
1044 South Shores Rd.
Jacksonville, FL 32207

P: 904-638-5431
E: james@developsec.com



Privacy Policy

© Copyright 2018 Developsec · All Rights Reserved