Security Testing | Security 4 No0bs - Basic Security Testing with Bug Magnet

Bug Magnet - The best tool a tester can have

What if I told you there's a super-simple tool that is easy to use and requires little to no effort to learn!

And what if I told you, no special downloads, CLI commands, or Kali Linux extensions were necessary!

Look no further .. BUG MAGNET .. is the answer!!

So What Is Bug Magnet?

Bug Magnet is a chrome extension you can use to test form submission and input sanitization. Easily the first step in any manual security testing effort. It features an expansive array of positive and negative test cases for a wide variety of options. Being that this is a security-minded blog post, with a sprinkling of QA, we'll consider a few exploits.

For the purposes of this demo, we are using the practice form here.

Exploit #1 - Buffer Overflow | Goal: Test that form inputs limit character entries to prevent data corruption, crashing the program, or cause the execution of malicious code

What is a buffer overflow? The short-version, a buffer overflow happens when copious amounts of form data is submitted that is more than the allocated memory space (buffer) can handle. For more details, visit OWASP | Buffer_Overflow Vulnerability. How to test:

1. Visit the form and pick one of any inputs shown
2. Right-Click into the input to open the context menu - look for bug magnet
3. Select Text Size and either with spaces or without
4. Once the text has been entered into the input submit the form
5. Repeat with another input, or all of them

Exploit #2 - SQL Injection | Goal: Form submissions block excution of queries

What is a SQL Injection? As the name implies, this exploit causes the site to execute a query on submission of the form. For more details, visit OWASP | SQL Injection. How to test:

1. Visit the form and pick one of any inputs shown
2. Right-Click into the input to open the context menu - look for bug magnet
3. Select Format Exploits this opens a tertiary context menu
4. Select SQL Injection - the first entry in this new context menu
5. Notice there is a script populating the form - Robert'); DROP TABLE Students;-- this can be modded to reflect a known table in your project codebase
6. Submit the form, note the outcome - in a perfect situation, nothing should be observed (ie, no harm done!)
7. Repeat with another input

Exploit #3 - Javascript Injection | Goal: Form submissions block excution of code by escaping special characters as text

What is a Javascript Injection? A javascript injection allows malicious code to execute within a form post-submission. It can be anything from an annoying pop-up alert to a remote-code executable. For more details, visit Portswigger | Javascript Injection. How to test:

1. Visit the form and pick one of any inputs shown
2. Right-Click into the input to open the context menu - look for bug magnet
3. Select Format Exploits this opens a tertiary context menu
4. Select Javascript Injection - the second entry in this new context menu
5. Notice there is a script populating the form - alert('Executing JS') --
6. Submit the form, note the outcome - in a perfect situation, nothing should be observed (ie, no harm done!)
7. Repeat with another input

Exploit #4 - XSS Injection | Goal: Form submissions block excution of code

What is a Cross-site Script Injection? Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. For more details, visit OWASP | XSS Injection. How to test:

1. Visit the form and pick one of any inputs shown
2. Right-Click into the input to open the context menu - look for bug magnet
3. Select Format Exploits this opens a tertiary context menu
4. Select JS String (XSS) Injection - Single Quote - the third entry in this new context menu
5. Notice there is a script populating the form
6. Submit the form, note the outcome -- nothing should be observed (ie, no harm done!)
7. Repeat with another input
8. Repeat this above test scenario with JS String (XSS) Injection - Double Quote

Exploit #5 - Broken HTML | Goal: Form escapes any special characters on submission

Broken html and HTML parsing are the lesser of the format exploits provided by Bug Magnet. What these options do is essentially inject simple html characters into an input that is not expected to allow such characters (ex: phone number or email input).

1. Visit the form and pick one of any inputs shown
2. Right-Click into the input to open the context menu - look for bug magnet
3. Select Format Exploits this opens a tertiary context menu
4. Select HTML Parsing - the fourth entry in this new context menu
5. Notice there some mild html entered into the form
6. Submit the form
7. Repeat with another input
8. Repeat this above test scenario with Broken HTML option

Security Testing | Security 4 No0bs - MITRE ATT&CK

Mitre ATT&CK

A brief, high-level "Blue Team" Cybersecurity defense framework. I won't be going too deep into the technicals of how it works, but I will cover some of the basics of what I'm learning. To illustrate the purpose of this framework, let's consider football - namely Offense vs Defense.

What is Mitre ATT&CK

In football, it is super-critical and advantageous for the Defense to know what the Offense is capable of, understand trends, and know how to respond. Basically, situational awareness. The Mitre Adversarial Tactics, Techniques & Common Knowledge is that "situational awareness" concept wrapped in a framework.

Imagine the scneario: 2nd quarter, game is tied, the Offense tends to throw a lot, but the situation warrants a run or run/pass option. As a Defender, it is imperative to know what to anticipate. Blue Team, aka Cybersecurity Defenders, must be able to "read & react" when a situation occurs that warrants further investigation.

The framework consists of 6 different actions to take:

1. Develop & Update Malicious Activity Model
• This is like the Defense's playbook. A model is an understanding for what the threat actor is doing, how, and why.
2. Develop Hypotheses and Abstract Analytics
• To understand what the Offense might do (or has done), a hypothesis is drafted. The hypothesis must be concise and succinct.
• Analytics serve to track the "how" of an attack.
3. Determine Data Requirements
• There's a long list of criteria that are factored in to writing up a good model, primarily with the efficacy of the data and its source.
4. Identify and Mitigate Data Collection Gaps
• Eliminate any likelihood of "escaped" data; that is, any missing or obsolete data from the model
5. Implement Test Analytics
• Use the constructed playbook to set up a Defensive posture.
6. Hunt / Detect Malicious Activity and Investigate
• Deploy the defense and have Red Teamers test it.

These 6 different actions iterate as many times as necessary. The goal of Defense is to have close to no false negatives for non-detected issues, and true positive results for detected issue (that is to say, Defense caught something truly malicious instead of confusing a benign action as a hostile one). The MITRE framework attempts to aggregate information from a wide array of resources to "read & react" to an event caught by intrusion detection or intrusion prevention system.

Blue Team spots something fishy on their scanners. The investigate and see something is up. Based on the attack pattern and area compromised, they can refer to their model to understand what the attack type is, what it is targeting and why, and how to craft a threat mitigation plan against it.

It is not a hard framework to learn, nor is it overly simplified. But this is a great thing to learn, do, and grow.

Ciao For Now!

Tune in next week, I will give a brief write-up on some cool attacks learned from Security+ and Network+

Security Testing | Security 4 No0bs - Burp Suite

Today's tool to learn: Burp Suite

So what is Burp Suite?

Burp Suite is a proxy tool that sits between your application and your computer. When configured to do so, it "reads" the interactions/requests of the application and allows you to interact with it in all kinds of ways. Interactions such as:

• With Target you can create a site map of the entire application and its pages for future use
• You can employ view the application requests with Proxy/HTTP History
• Intruder lets you configure automated attacks like Brute-force login
• The Repeaterallows you to intercept the request, modify it in some way, then send it back into the system. A really deadly tool in the hands of a skilled person

And this is just the tip of the proverbial iceberg. There are a plethora of features and functions to use. There's a Community Edition and a PRO version of Burp Suite. The Community Edition is a great introduction to learning how to proxy an application and play with the requests. The PRO version allows you to add a plethora of extensions that transform this platform into a powerful tool in your arsenal.

Why Burp Suite?

There might be many options available to use, but none can match Burp Suite's array of features. It is only limited by the mind of the user. The setup is simple and the learning curve is optimal.

How to use Burp Suite?

I won't go into the many many .. many ways to use Burp Suite, but I can offer a quick example. We'll use a simple scenario where you browse a fake website, visit the product details page, intercept the request to change the price, then send it and place the order:

1. To begin: download Burp Suite (Community or PRO)
2. If using Firefox, follow the directions on how to configure FoxyProxy. For chrome, no action needed.
3. Launch Burpsuite and skip past the options configure a new project. Simply click "Start.."
4. Once the application is launched, click Target > Open browser -> this opens a built-in Chromium instance that is pre-configured by Burp Suite to proxy the requests.
5. Paste the following url in the address bar: https://5elementslearning.dev/demosite/index.php
6. In Burp Suite, click Proxy > Http History. Pro-tip: right-click into the pane and click Clear History .. just to remove any noise from site navigation.
7. Browse the site and select a product to arrive at the product details page. Note the displayed price.
8. Add the item to the cart, then look for the request in Burp Suite
9. Right-click on the request and click send to Repeater
10. In the Repeater, scroll to where the price is displayed and modify it so the price is more to your liking then click the SEND button.
11. Proceed through the checkout flow with product and it's new price. If the price reverts, change it again in the final step before submission.

Et Voila! You have just 'hacked' an e-commerce site. Congratulations!! This is one of many many ... many scenarios you can learn via the labs.

For the complete list of labs, visit: portswigger.net/web-security/all-labs

Ciao For Now!

Tune in next week, I will give a brief write-up on MITRE ATT&CK and this cool book I've been reading.

Security Testing | Security 4 No0bs - Finding Your Path

The Video: How To Find YOUR career path in Cybersecurity - 2023 (Live) Ed.

hosted by: @monicatalkscyber & @mikemillercyber | Streamed live on Feb 8, 2023 | https://www.youtube.com/live/ikzsvxR0T5Q

“He who has a Why can endure any How.” ― Frederick Nietzsche

I wanted to pivot from my promised discussion on Burp Suite to discuss the purpose of having a path (based on a video I watched). It was about an hour or so discussion on a wide range of Cybersecurity themes around the topic of "getting started", namely how. Here's what I learned:

1. Know Your Why

As I discussed in my previous post, having a "why" is essential to the journey. When you know the purpose of what you are doing you can go about taking the necessary steps to make it happen. I won't belabor the point of the "why", but I know why I want to get into Cybersecurity. My question now is how to get where I'm going. It can be easy to get lost in the noise. There are so many things that are cool to know and do.

2. Find A Niche That Aligns With Your Passion

Reigning in the varied interests has been the hardest part my learning so far. I know I need to know about Networking, but it gets boring. I know I need to pay attention to Security+ topics, but understanding tooling is just as important. Then there's topics like Threat Modelling and Threat Hunting that speak to me. As someone with a background in testing, the foundation is in place, but deciding what to choose is tough when everything speaks to me. I'm still on the fence between actual Pen Testing or Threat Hunting.

3. Know How To Communicate

Another key topic in the video that was greatly emphasized was communication skills. Rather than call them "soft" skills, it was stressed that this should be regarded as a required skill.Being able to discuss complex topics to non-technical individuals, reporting findings, or selling the need for a particular tool is essential to the job.

4. Have People Skills

Along with solid Communication skills are "People skills". Knowing your audience is a talent. Making friends and influencing others is truly an art that is also essential to the job. People skills can mean anything from knowing whom to approach when an incident occurs, to knowing how to take initiative and deliver instructions in the event of a natural emergency. Cybersecurity is way more than just the 1s and 0s in a terminal.

5. Choose A Specialty & Expand Outward

Bringing it back to the topic of a specialty, the hosts of the video recommended choosing a specific specialty, learn it, and work to expand onto other fields. It's not far fetch to imagine someone starting out as an Auditor and eventually pivot to Risk Assesment, or "Blue Teaming". The take-away: there is no linear trajectory.

6. Work On Your Brand

The hosts - Monica & Mike - mentioned the idea of selling yourself as a "brand". A brand - a product or service - consists of a recognizable name and a reputation. I have a hard time with this as I am actively working to repair my reputation from previous instances of past mistakes and what-not! The brand that is me is long overdue for a revamp. And orienting myself towards this new endeavor is a great way to start. As someone that needs to get started in Cybersecurity, being a service to the company implies adding value and being indispensible. That's the goal. Answer the questions, "who are you?" and "what can you do for me?"

7. Showcase Your Knowledge

When you have an established brand, and set of skills, the next thing they mentioned was "selling your knowledge." The dichotomy of showcasing your talent is coming off like you need attention. You have to highlight what you know, but do it in a manner that doesn't appear vain. Personally, I prefer being the "silent option" - get in, do the job, get out .. no need for accolades or glory.

8. Network, Network, Network

As stated earlier, along with the need to build a brand is exposure. Getting started in Cybersecurity is equal parts what you know and who you know. The hosts in the video stressed the idea of networking as the key to get started. Follow companies, interact with posts, promote your own knowledge, even attend meet-ups and the like. Anything to interface with professionals in the industry is fundamental to getting noticed and even bypassing the traditional HR routes. This is something I'm actively working through.

9. Get Certified

The topic of certification is somewhat contraversial. On the one hand, it's not about the paper certification but rather the experience. On the other hand, certification is proof of competency. One thing is certain, there are definite certifications I plan to pursue and when money get's good, they will happen.

10. Pay It Forward

Paying it forward was not discussed in the video, but it is something I promised myself I would do when I get proficient in my craft. As I have been mentored, I have also done a lot of self-paced education and marking down the things I have learned. If nothing else, this has helped reign in the many many ideas I have to want to learn. It is important to know where you are going and why. I would love to pass on this knowledge to the next person who decides they want to pursue this career.

Conclusion: Your Path Is Not A Straight Line, But Rather A Long Windy Road!

Overall it was a great video. There was a lot I already know, and a couple of new things I learned. The greatest take-away of all was the idea that there is no linear path. There is no explicit time-table for getting started. There is nothing to hold you back from your passions except you. You have to know your why and you have to grind. There will be times when doubt creeps in. When Imposter Syndrome rears it's ugly head. Those are the times you have to get your mind right. When you now your why, you can endure any how. You can get after it! And I plan to get after it.

Til next time ... Ciao For Now!

Security Testing | Security 4 No0bs - The Importance of Your "Why"

Knowing your why can determine your how

Hello Reader,
I rececntly came across a post on my LinkedIn feed in which the author wrote about a few questions that were introspective. I wanted to take a few minutes from my usual posts about tools and tactics to discuss why we are doing what we do. Why am I learning Cybersecurity? What are my goals? How will I get where I want to go?

Knowing our why is super-critical to determining the how. As I progress through this learning journey, I am often overwhelmed with the amount of information being disseminated. Things like "40 YouTube channels to checkout", "33 Websites to learn Cybersecurity for free", add 500 new connections today. OMFG! way too noisy!. It is critical to silence the noise and get to what is real. Here are the questions posted that you can ask yourself. I will post my answer below.

“I want to go into cyber because _______”

I never considered Cybersecurity as a career path. I stepped in it as a choice when selecting a track to focus while studying at Devry IT. I enrolled with the pretext of learning some basic computer skills, perhaps web development. This was all before boot camps like Flat Iron or General Assembly. There was a call for people to sign up and choose a particular path rather than general studies. Been in love since.

Sadly the school was inadequate in terms of teaching professionals, and to have made the most of my learning I would have had to continue in their 'Masters' program. I was already disappointed with the last year in school, and had to take out a bunch of loans just to finish.

To answer the question concretely, I want to get into cyber because (a) it will be a lateral move from my current station as a QA Engineer, and (b) I absolutely love the learning process and hunting for exploits.

“I want this company because _______”

I have yet to hang my hat on any one company, but there are several companies that speak to me in terms of what they do. BrightSec is a company that specializes in dynamic application security testing (DAST). They would be cool to learn from. Red Balloon is legit! Gremlin is a company I just interviewed for that employs different attacks to test site reliability. Overall, any company that is cool and can teach me something is the one for me.

“I want this role because _______”

I am still working through the exact role I want to occupy, but Pen Tester seems like the obvious choice. The start to Cyber seems to be in compliance, but threat modelling intrigues me. Overall, I would answer this question by saying I want the role of Pen Tester because it is a natural fit for skills and experience .. plus it is just too damn fun! Purple Team is the dream.

Conclusion:

Knowing your why is like having a latern in a dark forest. It will guide you. Structure your learning, orient your goals, and align your career objectives to those goals. When you know your why, those late nights grinding through boring lessons and tedious acronyms will make sense.

Ciao For Now!

Tune in next week, I will give a brief write-up on Burp Suite and some of the cool things I have learned.

Security Testing | Security 4 No0bs - GDPR Basics

A quick n' dirty breakdown of GDPR and why it is important

Hello Reader!

In this installment of Security 4 NoObs we will be discussing GDPR - the General Data Protection Regulation

Anytime you visit a website, be it in the United States, or Europe, you are prompted with a banner to accept/decline cookies. It's a little checkbox (boolean) that carries a lot of value. On the surface, you tick off a box (or not) and the banner goes away. Behind the scenes a vast system of logic rules kicks into gear, the purpose of which is to collect and store "cookie" data as it relates to you when browsing that site.

A cookie can look something like this:

• To learn how cookies are made, visit: Make-a-Tracking-Cookie
• For a quick read on how cookies work, visit: what-are-tracking-cookies

Why this matters

How data is collected is actually a big deal. Users have agency over how their data is to be handled and disseminated. The option to accept/decline tracking cookies gives the user the power to give consent to their data. Below are some quick notes on the specific details of how it works. Some glossary terms to note:

• Member State: any acting government / governing body complying with GDPR
• Controller: the product or service collecting the data
• Collected for an explicit purpose at the consent of the consumer (data subject) visiting said site; not retained longer than necessary
• Minors (~16yrs) require the consent of a parent (adult)

How it works

For a comprehensive reading of GDPR, written in a lot of legal-ese, please visit: gdpr-info.eu. Below are some key take-aways:

1. Users have the right to be forgotten, as requested
2. Users have the right to be informed when their data is being handled/transferred
3. Users have the right to have their information wiped upon request
4. Users have the right to object if their feel their PII is mishandled
5. Processing ensures C.I.A of data
6. If a breach occurs, notice to all impacted users must happen within 72hrs
7. An official is to be appointed:
• The Official will be solely responsible for all particulars of data
• It is expected that this official will cooperate with any other authority figure as the need warrants
• Any necessary investigation will be conducted jointly
8. Reports will be drawn yearly to show the state of application of guidelines
9. A board / committee will be created for the overall governance of said guidelines:
• Any ratifications require 2/3rds vote
• A chairperson will be appointed
• The board will have a proper e-board, incl. A Secretary
10. The board handles any complaints filed against mishandling of info.
11. Users have the right to sue if their data gets mishandled:
• Controller and/or Processor may be held liable, as the evidence warrants
• The fine cannot be crazy excessive, max = $20M
12. Every 4 years starting 5/25/2020, the Commission is expected to send a report on the evaluation and review of the regulation to European Parliament & The Council; available to the public

When it goes wrong

It is important to mention that European regulations for data management are somewhat different than those in the United States. A violation of the GDPR can have major consequences, as in the following issue with TikTok: tiktok-fined-54-million-by-french

Conclusion:

Consumers (visitors to a website) have the right to understand how their information is being used by Companies and how to ensure their privacy is not being violated. Next time you visit a website and get a prompt to accept/decline cookies, you'll know the true power you have over your information and how it should be used.

END OF LINE

Security Testing | Security 4 No0bs - Saying 'Yay' to BYOA

How could BYOA (bring your own application) play a part in security?

Source - Ministry of Testing - 30 Days of Security Testing Challenge (2017)

Dear reader, I'd like to take a few minutes to present my take on this whole idea of personal apps on personal devices whiles on company time. Seems like the issue of BYOA is ever-increasing as more and more business adopt cloud-based solutions for things like data storage, design, collaboration, and the like. Using the metaphor of a box as security, every user with a personal device using their own apps is poking holes in the box. It's not hyperbole to regard each app (non-Company Approved)as a potential attack proxy.

With that said, the following is a list of things off the top of my head that I see as issues resulting from BYOA. Its a simple list and I'm sure more can be added as IoT evolves:

What is BYOA?

As it is defined in most places, BYOA (Bring your own application) is the practice of using third-party applications. This can be anything cloud-based, external-facing, or otherwise remotely accessible.

The problem inherent in this practice stems from individuals, with personal devices, introducing apps that can utilize the same resources as other applications in the system, in essence making them "friendly".

What harm can it do?

1. Cloud-storage Apps

Locally, users may be able to store and retrieve data from a centralized system. Monitors are put in place to track the flow of data, and roles-based access determines who gets what.

The challenge is how to control this stream of data in the cloud.
Authentication credentials may provide some form of control, but the likelihood of a data breach, social engineering attack, or other means of accessing the server is high.

2. Collaboration Apps

On the surface, collaboration apps appear harmless, but if an application not approved by Network Administrators is used, there is the potential for exposure to attacks not limited to trojan horses or packet sniffing.
Network Admins may have a tough task of regulating what is / is not admissable on the network.

3. Social Network Apps

Another potential attack vector, social network apps present the opportunity of introducing malware into the system by way of interacting with the wifi, blue-tooth connection, and distinct device settings.
All one has to do to introduce such an attack is simply click on a link, post, or image and **BOOM** an attack has begun.

What should I do?

Granted there are more scenarios that illustrate the point I'm trying to make about BYOA, but the solutions to ensuring the chance that a security incident never occurs is to be mindful of the apps in use.

While at work, be to use apps approved for work use only, and be cognizant that any communication using company resources will be monitored. Any suspicious activity will be flagged.

What should I NOT do?

The answer to this is simple:

1. Don't use "your" apps for work

As an employee (end-user), one should strive to avoid using any unapproved applications.

2. Don't use "your" social apps during work hours

Avoid sharing anything, clicking anything, streaming anything, or downloading anything not work related.

3. Don't store anything in the cloud

Storing copies of any company information remotely. This may be construed as a security policy violation with dire consequences.

Conclusion

As a user ...

Keep a close eye on the apps that you ARE using, especially ones approved for work, and keep any non-work related activity for when you are off the clock.

As innocuous as it may be, the idea of BYOA is novel but perilous. The transmission of information - Inbound / Outbound - is a security risk no organization can afford.

Security Testing | Security 4 No0bs - Web vs Mobile Security Testing

Web vs Mobile Security Testing: A No0b's Observation

Dearest Reader, As I am moving along in my journey towards learning more about information security and testing, I've come to understand how the pieces fit.

While my testing experience began with mobile, a lot of the testing principles carried themselves to the web. Browser nuances aside, I've noticed distinct similarities in how applications work, and some obvious differences.

The same can be said with regards to security testing.

How Web & Mobile are the similar

Some of the similarities I've encountered with regards to Mobile versus Web Application Security Testing include:

1. Browser behavior
So the first thing I've come to realize is just how similar web and mobile behave. As it relates to presentation, the UI interactions are identical. A mobile-friendly site can elicit the same response as a native app. This presents the ideal playground for hackers to take action. A user can view a site or install an app from a "trusted" source and unknowingly introduce trojan horses in their system. Its been reported just how rampant the spread of malware is from trusted app stores.
2. SQL / JS Attacks
In my testing experience, I've come across both web and app forms that fail to follow certain design patterns. The first of these patterns being max field length constraints. All-too-easy to enter verbose text and cause a crash or other negative behavior.
Another common situation involves the lack of proper input restrictions. While easier to mitigate on web, more often than not the likelihood of injecting malicious code into a form is evident when the controls to prevent special characters from being entered are not found.
Imagine being able to trigger a "DROP TABLE" command from a form that isn't preventing the system keyboard from entering special characters where none are expected. Not good!
3. Data Manipulation - MITM
While this required a little more effort, the means by which submitted data could be manipulated occurred the same way both on web and mobile devices. Some time ago, I was tasked with testing an app that required user input in order to trigger an SMS operation.
With the help of a proxy tool, I was able to manipulate the payload and transmit gibberish where a legible message was expected. I've successfully done this on web sites as well.
4. Session Hijacking Attacks
Because web and mobile apps rely on cookies for state-transitions and navigation, the means by which sessions can be hijacked are identical. With the help of proxy tools, session tokens can be intercepted and manipulated, wreaking all kinds of havoc.

How Web & Mobile are completely different

In my opinion, not a lot separates web from mobile aside from the obvious differences in resource and hardware. There may be more to this list than I can possibly mention, but I shall endeavor to keep it short and sweet.

1. Native SDKs
So the first thing to mention is the SDKs. In this category, iOS (Apple) has the clear advantage with regards to how it manages its application universe. With the way they handle release management and policies regarding application submission, Apple ensures its operating system remains tamper-proof. But recent exploits have shown nothing is unbreakable.
Security testing apps involves using a lot of proprietary tools and the biggest challenge is overcoming the iOS restrictions.

Android, written in JAVA, presents an implicitly easier way of testing apps from a security stand-point. The biggest challenge however, is the device ecosystem. While testing may prove stout in many of the devices, lower-tiered devices using a legacy-version of the Android OS may prove likely targets as their code-base might be not patched.

2. Tools To Use
In my experience, working with native apps and web sites, the tooling for security testing is diverse. That being said, the one tool I found working the best way was BurpSuite.
Where the differences lie are in how you proxy the device to interact with the framework. On a website, one just sets the IP address to be detected by the proxy tool and VOILA! you are being detected.
With mobile devices, one has to create a Certificate with the proxy credentials. Then the certificate must be installed onto the device. Lastly, the device wifi and proxy suite must reside on the same network.
Another key difference was applying OWASP Top-10 test cases. The test cases for web did not translate 100% to mobile, and vice-versa (ie., there were subtle nuances to account for).
3. Attack Vectors
As stated before, while the device ecosystem is stout for iOS, this is the complete opposite for Android.
There are a plethora of devices, OS versions, and other fractious iterations in the wild, not to mention rooted devices, that testing and securing platforms proves an enormous endeavor.

Conclusion

This list is in its infancy and may evolve over time, but for now .. this is what I got!

• OWASP_Testing_Project
• source.android.com/security/
• iOS_Security_Guide.pdf

Security Testing | Security 4 No0bs - Personal Wiki on Information Security Stuff

Running into a lot of great articles, stashing them here:

• OWASP Top 10 Cheat Sheet
• DNS Spoofing (Wiki)
• SSL Roadmap (Wiki)

Security Testing | Security 4 No0bs - Whats the RISK?

Risk Assessment: Web Application Security Testing (pt.3)

Hey all,

In my previous post - Requirements - The Gathering - I briefly discussed requirements best-practices and what it takes to get to analyzing a story and drafting best possible test scenarios. From these scenarios, we get a list of potential requirements for the feature - in this case, login. With that, let's discuss risk assessment.

Below is the list of requirements derived from the previous post

• Login form fields are required
• Login form allows for only alpha-numeric data; where expected special characters are permitted
• Login username is to allow a finite number of text (or check for e-mail input)
• Login password field allows a finite number of characters, of a particular format
• Login form field password text field is to be masked
• Login error messages must be in the right font-style and color
• Login error messages must not communicate what the expected input should be
• Login authentication must redirect user the proper destination - cannot be hijacked
• Login session is managed server-side
• Login url must not past authentication parameters
• Login authentication cannot be manipulated in any way, giving non-auth'd users admin privileges

Now, let's look into: Threat Modeling

source: https://www.owasp.org/index.php/Threat_Risk_Modeling Threat modeling consists of 5 basic steps:

1. Identify Security Objectives

2. Survey the Application

3. Decompose it

4. Identify Threats

5. Identify Vulnerabilities

Security Testing | Security 4 No0bs - Posture Assessment For An Application

Continuing our "Security 4 No0bs" series, I want to discuss what exactly is this thing called a "Posture Assessment" and how it applies to information security

 

Source: Secure Force - Security Posture Assessment

What is a Security Posture Assessment?

In a way, the Security Posture Assessment (SPA) is kind of like a S.M.A.R.T goal for an organization, as it relates to cyber readiness. The text definition is, "an organization needs to be able to assess their cyber-readiness holistically."

How does it work?

Applying the S.M.A.R.T principle, we can say that an organization can determine their cyber-readiness by setting forth an assessment based on the following (simplified) list:

1. Specific

An assessment of the current state of the security posture is conducted by way of an audit, be it internally or externally; an assessment of the security posture at both a micro and macro level. Based on the results, potential solutions are presented.

2. Measurable

The impact of what was discovered during the audit needs to have some weight (value) associated with it. This can be in the form of a Severity "1-to-5" or "Critical > High > Medium > Low" scale. Whatever is used, the point is to assign a value to the issue so as to take the appropriate response.

3. Achievable

Once solutions are provided, the tactical feasibility is taken in to account. These solutions can become part of an overall program, be it Disaster Planning & Response (DRP) or Continuity of Operations Planning Program (COOP). The solutions outlined must be able to be accomplished within a reasonable time frame and within a budget of some kind.

4. Relevant

The combined results (a Vulnerability Scan performed + Audit + Security Assessment) should be modeled against the security architecture in place. The end result is a concise list of actionable items carrying a point-value and criticality metric relevant to the application or business function.

5. Time-Based

As stated before, the SPA ought to have some degree of efficiency as it pertains to INPUT -> PROCESS -> OUTPUT.

• INPUT

  Initiation of a SPA ought to begin based on a request (trigger) or response to perceived issue, in a timely manner

• PROCESS

  The scope of the SPA can be achieved when all the necessary information is acquired on time. Same goes for completion of any vulnerability scans, security audits, and other such assessments.

• OUTPUT

  The overall conclusion of the SPA has an expressed date and time, but by no means is to be regarded as finished. One can define "Done" as: submitted comprehensive list of recommendations via report, waiting on response and follow-through.

Why bother with this?

In this day-and-age, cyber security is paramount to business continuity as well as web and mobile application security. A SPA, taken as part of a larger comprehensive cyber readiness initiative, adds an immense value to the overall constitution of an organization. It is imperative to the integrity and reputation of a company of any size to get "cyber ready" post haste.

Security Testing | Security 4 No0bs - 5 Steps to a quick Security Audit

The process and procedures around Security Auditing

*** Disclaimer, as I'm learning about Information Security I come across a lot of useful information. Truly, its a firehose of facts, tips, etc. that I write on this blog. As it were, I wish to post the following link along with my notes on the following topic - Security Audit. ***

blog.dashlane.com/conduct-internal-security-audit/

What is a Security Audit?

At its most basic, a Security Audit is a systematic technical assessment of a system or application. The Security Team will conduct interviews, perform all manner of vulnerability scans, analyze the results, and produce a report detailing areas that require attention.

An audit must be thorough, cost-effective (in both time and money),
and free of bias

A more expansive definition can be found by conducting an online search or visiting your local library or bookstore.

Who is this for?

Audits can be applied to banking, commercial, health care organizations, schools, and just about any other institution where there is an exchange or transmission of sensitive end-user data.

Why am I doing this?

As mentioned, anytime a transmission of sensitive user information is involved, there needs to be precautions taken to secure the data. Think: Banking or Retail Site using banking information to complete a transaction.

The CIA triad comes into play.

An audit guarantees data is kept confidential during processing, its integrity is preserved during transmission, and that it is accessible only to the recipients involved.

Security Audits are performed at the behest of a company about to launch an application employing sensitive user data. Another occasion an audit is conducted is mostly as a result of enforcement intervention (ie, a cyber crime was committed ). An investigation must be conducted to determine culpability by way of negligence, willful or otherwise.

Where will it take place?

More often than not, security audits are conducted on-site under the supervision of a third-party agency. Audits can be done internally or externally, the latter being more thorough but expensive.

External audits are performed by seasoned professionals who have all the appropriate tools and software to conduct a thorough audit   — assuming they receive the requisite data and direction

What is in scope?

Should you decide to conduct an internal audit, and you've educated yourself in the compliance requirements necessary to uphold security protocols. Do the following:

1. Define Your Audit
2. Define Your Threats
3. Assess Current Security Performance
4. Prioritize (Risk Scoring)
5. Formulate Security Solutions

What is not in scope?

Anything not otherwise agreed-to, as expressed in the contractual agreement, entered into by the auditor at the request of the client

What is to be audited and what is not will be documented in a list - Valued Assets - and divided into segments of what will / will not be audited. The assets declared highest value is where the focus of the audit should be.

How long does it take?

Start-to-finish, a security audit duration is determined by the scope and list of assets, as well as the volume of potential threats. Audits can span days or weeks. Most importantly, security audits are iterative and ought to be conducted regularly.

What are my deliverables?

Based on the outcome of the audit, a comprehensive report is generated detailing the level of tests conducted, any issues requiring action, and a list of potential security solutions. These can cover anything from "Employee Awareness" seminars, defensive counter-measures, better password policies, and network monitoring. 

This list can go on and on, but it is reliant mostly on the results of the aforementioned audit.

Security Testing | Security 4 No0bs - Requirements: The Gathering

Performing a Security analysis for requirements in a story  Web Application Security Testing (pt.2)

Hey all,

In my previous post - Getting started using a WBS - I posted a draft of a WBS that is usable for the project you are assigned to, from a testing perspective. It is by no means a finished product and can be customized as needed. Below I'm going to discuss performing a security analysis for requirements in a story.

1.0 - Requirements Best Practices

Source: http://agilemodeling.com/essays/agileRequirementsBestPractices.htm

• Stakeholders actively participate
• Adopt inclusive models
• Take breadth-first approach
• Model storm details just in time (JIT)
• Treat requirements like a prioritized stack
• Prefer executable requirements over static documentation
• Implement requirements
• Create platform-agnostic requirements
• Create smaller, digestible requirements
• Question traceability
• Explain requirements gathering techniques
• Adopt stakeholder terminology (speak 1 language)
• Keep it fun
• Get Management support
• Turn stakeholders into developers

2.0 - Use Case (sample)

The context for this feature is login functionality for an e-commerce website, where visitors (new Customers) can opt to create accounts so as to facilitate order tracking, adding items to a wishlist, or simply expediting the checkout process. Visitors can register at any time simply navigating the the registration form from the link in the navigation header, or during checkout after adding items to their cart.

ID	ELEMENT	DESCRIPTION	PRIOR RESEARCH
1	User logs in	Registered members of the site can access their profile, dashboard, etc.	Single-sign on necessary for returning customers
Goal	Customers will freely interact with E-Comm agents	Customer Account Management	Client Services Analysis, 2016
Actors	E-Comm Reps, Registered Users	Agents can resolve customer issues; Customers can track their orders	Client Services Analysis, 2016
Pre-Condition	Customer record in DB	User is to have successfully registered in the system	CMS Integration
Post-condition	Profile page; login credentials	Successful subscription will create a profile with USN and avatar	CMS Integration
Trigger	Link in header / cart page	Guest users can opt to register from nav header or during checkout	N/A
Exceptions	Form validation rules	Required field and standard validation rules enforced	CMS Integration

3.0 - Security Analysis

Now that we've identified a feature in test, let's consider the security implications
source: OWASP TOP 10 for 2013

TEST CASE	ELEMENT	DESCRIPTION	SECURITY ANALYSIS
Login authentication	User logs in	Registered members of the site can access their profile, dashboard, etc.	Single sign-on necessary for returning customers; authentication protocols are enforced
Required Fields	Validation rules	Error messages shown on-submit	Messages should not convey the nature of what is wrong, or hint at what should be expected
Boundary Test	Max field lengths	Correspond to data structure in the DB	Should only allow for what is expected in the DB, no more
Character Test	Alpha-numeric data types	Text input validation for expected entry (ex: phone number = numeric keypad)	Non-numeric (ASCII) characters are to be inadmissible on-submit of form
SQL Injection	Commands in text fields	Error handling for script calls	SQL or any other such query language is to be inadmissible on-submit of form
Broken Authentication	Testing password, keys, session tokens, etc	Login authentication is to be handled securely by the server	Verify login authentication can't be compromised; session can't be hijacked; cookies can't be manipulated, and so on
Cross-site scripting	Authentication: session hijacking by way of XSS script	Data transmitted is validated or escaped	Test that XSS is not possible; data is transmitted properly
Insecure Direct Object Reference	Test for Exposure to a file, directory or key	Authentication is valid	User should not see references to file, directory, or the like exposed in the url post-authentication
Sensitive Data Exposure	Testing for exposure to sensitive data post-authentication	Authentication is secured	Sensitive data is adequately protected (stored, encrypted)
Cross-site Request Forgery	Login Redirect	On-submit, user is redirected to the expected destination	CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application.
Unvalidated Redirects	Login Redirect	System redirect for authenticated user operates as expected	Web applications frequently redirect and forward users to other pages and websites. This should not be the case at log in

4.0 - Requirements

Having scoped the feature, and mapped out some security scenarios, we've fleshed out some potential requirements:

• Login form fields are required
• Login form allows for only alpha-numeric data; where expected special characters are permitted
• Login username is to allow a finite number of text (or check for e-mail input)
• Login password field allows a finite number of characters, of a particular format
• Login form field password text field is to be masked
• Login error messages must be in the right font-style and color
• Login error messages must not communicate what the expected input should be
• Login authentication must redirect user the proper destination - cannot be hijacked
• Login session is managed server-side
• Login url must not past authentication parameters
• Login authentication cannot be manipulated in any way, giving non-auth'd users admin privileges

As you can see, the list can get pretty lengthy. And this is just the beginning!

Security Testing | Security 4 No0bs - Getting started by using a WBS

Applying Project Management fundamentals to Quality Assurance, as it relates to  Web Application Security Testing (pt.1)

Hey all,

This year, my focus is to ramp up my Info Sec. / Web App Security learning and stumbled upon this gem from last year. Figured I could re-purpose it for Security Testing. The scope of this "part 1" is to take the approach of someone assigned to a project and applying old-school practices to get started.

Some of this may work, some of it may not. But the foundation is laid out and it goes something like this:
 

1.0 - Objective

   1.1 - Define testing agenda and purpose of document as it relates to Security
           1.1.1 - Get Project Summary
           1.1.2 - Get S.O.W

2.0 - Testing Scope

   2.1 - Establish what is to be tested
          2.1.1 - Get Testing Requirements from PO / Project Lead / Devs
          2.1.2 - Get Testing Bounds (what won't be tested / out of scope)

   2.2 - Determine level of effort for test tasks
           2.2.1 - Test Types and Duration
           2.2.2 - Test Task Dependencies & Schedule (when to start a new cycle)

3.0 - Personnel

   3.1 - Who are the Client and Stakeholders involved
           3.1.1 - Get names from PO / Project Lead / Devs

   3.2 - Who are the other members on the team (PO / Devs / BA / QA / etc.)
           3.2.1 - Have Kick-off Meeting
           3.2.2 - Get Names, Roles & Responsibilities

4.0 - Security Software & Test Strategy

    4.1 - What Software will be used
            4.1 - Meet w. PM / Devs / QA
            4.2- Discuss best applications / programs to use
            4.3- Discuss testing strategy (best approach) as it relates to OWASP Top-10

5.0 - Risk

    5.1 - Establish risk matrix from features-in-test
            5.1.1 - Meet with PM / BA / Devs
            5.1.2 - Get Risk Analysis from BRD

6.0 - Entrance / Exit Criteria

     6.1 - Determine when testing is to begin
            6.1.1 - Meet with PM / Devs / QA Team
            6.1.2 - Get Release schedules / Test Cycle schedules

7.0 - Completion Criteria

     7.1 - Determine when testing is complete
            7.1.1 - Establish sweep-completion ETA

8.0 - Glossary

      8.1 - Write up all terms, acronyms, and defined language in use
             8.1.1 - Draft list of terms and definitions (including CTAs, navigation end-points)

9.0 - Approval

      9.1 - Sign-off by all parties involved