This document discusses hunting for vulnerabilities across interconnected applications. It describes two cases where the author found multiple vulnerabilities by exploring dependencies between applications. In the first case, they discovered vulnerabilities by interacting with a desktop application and related web applications from the same company, finding 5 vulnerabilities including XSS issues and information disclosures. In the second case, they used a single sign-on system across multiple applications to introduce persistent XSS vulnerabilities. The document advocates considering how applications integrate and interact to uncover "inter-application vulnerabilities" that may not be found through isolated testing.

1. Inter-application vulnerabilities
hunting for bugs in secure applications
Marcin Szydlowski
@securityksl
OWASP Poland Day - Wroclaw 16th of October 2019

2. #whoami
• Marcin Szydlowski (@securityksl)
• Worked as a cybersecurity
consultant (pentests, red team, etc.)
• Currently responsible for secure
system deployment in a global
company
• Bug bounty hunter & member of
Synack Red Team (rank 0x03)
• Participated in programmes such as
Hack the Pentagon, United Airlines
and number of private programmes
via Synack and HackerOne

3. Hunting for
bugs in secure
applications
• Changed company, started to participate
in Bug Bounty programmes regularly
• Regularly does not mean full-time (nor
part-time)
• Dark side of bug bounty programmes
exists

4. Problem
statement
How to find unique vulnerabilities in web
applications of security-mature companies
in a limited time?

5. How your pentest environment looks like?
HTTPS
test.example.comUser

6. How the production environment looks like?
HTTPS
example.comUser
mail.example.com
user.example.com
legacy.example.com

7. How the production environment looks like in 2019?
HTTPS
api.example.com
example.com
User
mail.example.com
user.example.com
legacy.example.com
Caching server/LB/WAF
OAUTH
other.example.com
S3 example.com
HTTPS
HTTPS

8. Who
covers the
delta?
• „Only ZYX functionalities are in scope”
• „E-mail sending is disabled not to flood our helpdesk
with e-mails”
• „Test environment is isolated from the Internet for
security reasons”
• „XYZ functionality is out of scope as it is not ready
yet”
• „Other components have already been tested by
other independent companies”
• „Integration with other systems will be performed
once we know our application is secure”
Integration testing to the rescue?

9. What is in scope of integration testing?
Integration testing (sometimes called integration and testing, abbreviated I&T) is the phase in software
testing in which individual software modules are combined and tested as a group. Integration testing is
conducted to evaluate the compliance of a system or component with specified functional requirements.

10. Integration testing - Venn diagram
People who
understand
system B
People involved in
integration testing
Pentesters
(security
people)
People who
understand
system A

11. Integration testing – reality kicks in
People who
understand
system A
People who
understand
system B
Pentesters
(security
people)
People
involved in
integration
testing

12. Am I
exploiting
the
technology
or the
process?
• Web application security testing covers only specific
components of the system as it is often performed on
isolated or non-fully developed environment
• Pentesters often do not understand the business process
behind the application
• Various applications (system components) are tested by
various teams (or even companies)
• Responsibility for integration testing is often blurred
• Security is not the first priority of integration testing
PROFIT!!!
Acceptance rate - 44%
27 unique vulnerabilities reported in 11 months
Probably testing for less then 5 hours/week on average

13. The
Definition
Inter-application vulnerabilities - Vulnerabilities, which
require playing with at least two different systems (or
system components) to be exploited successfully.

14. Case #1 - Story of a desktop application
• Major international company
• Set of web applications in scope
• No vulnerabilities identified in the last couple of months
• Google recon identified that users e-mail addresses are disclosed via Google searches as they
are transmitted in GET parameter
• It was not possible to identify that particular endpoint during application walkthrough
Some other application component must exist

15. Money for nothing and XSSes for free
• Desktop application of that vendor publicly available for download after registration
• Most of the functionalities were not resulting in any requests being sent to the web server,
but...
• License renewal and forgot password functionalities resulted in HTTP requests with the
parameters never encountered before.
• Two XSSes with <script>alert(1)</script> payload right away (Bounty! X2).
• Forgot password mechanism - root cause of e-mail address disclosure identified (Bounty!)
• More was yet to come...

16. Fun part begins
• So how this license renewal mechanism actualy works?
POST /license.aspx
Host: renewal.example.com
ID=123456 renewal.example.com
User
Here is your license number!
AVX123ZSAJ1213124
I’m redirecting you to buy.example.com
And by the way here you
also have license
numbers of other users
as this is clearly
vulnerable to IDOR...
This is my license number and I’m authenticated
as Marcin I want to renew my license.
buy.example.com
Redirecting you to payment page where you have
info on subscribtion days left

17. What confidential actually means?
• So we have a huge number of license IDs – potentially all of them.
• Do not mix license IDs with license keys.
• Who really knows if some data is confidential? What makes it confidential?
• License numbers allows you to get more info on product type and number subscription days
left
• Not really confidential data :(
• But...

18. Inter-application dependency kicks in!
• There is one more web application of the same vendor, which allows (surprise surprise) to
renew licenses 
• So you are authenticated in the application, you provide your license ID and you are redirected
to the very same payment page.
• But what happens when you are not authenticated?

19. Inter-application dependency kicks in!
POST /license.aspx
Host: renewal2.example.com
LicenseID=AVX123ZSAJ1213124
You need to authenticate. Let me redirect you to the
login web page. I will provide the e-mail address
associated with this LicenseID to speed up
authentication process.
renewal2.example.com
User
Insecure direct object reference leads to disclosure of e-mail addresses of all customers (Bounty!)

20. We are not done yet.
So we are redirected to authentication web page and our e-mail is automatically submitted. How does it work?
GET
/redirect.aspx?email=ksl@test.com&othe
rparameters...
Host: renewal2.example.com
renewal2.example.com
User
You need to authenticate. Let me redirect you to
the SSO web page. I will provide e-mail address
associated with this LicenseID automatically.
Login page with your email
sso.example.com
302 – let me redirect you to
sso.example.com?code=base64string
(not decryptable)

21. We are not done yet.
So we are redirected to authentication web page and our e-mail is automatically submitted. How does it work?
GET
/redirect.aspx?email=”><script>alert(1
)</script>&otherparameters...
Host: renewal2.example.com
renewal2.example.com
User
You need to authenticate. Let me redirect you to
the SSO web page. I will provide e-mail address
associated with this LicenseID automatically.
Login page with your email. XSS in e-mail field!
sso.example.com
302 – let me redirect you to
sso.example.com?code=base64string
(not decryptable)
Reflected XSS on login page (Bounty!)

22. Case #1 - Summary
• 3 Reflected Cross-Site Scriptings on critical subdomains
• One IDOR vulnerability leading to complete disclosure of customer database (e-mails)
• Incorrectly set indexing protection leading to disclosure of user e-mails in Google
• 5 bounties for 5 vulnerabilities identified only by downloading a single desktop application
• Identified XSSes were exploitable with basic XSS payload - <script>alert(1)</script>
• 4 out of 5 were well-known vulnerabilities - listed in last 3 editions of OWASP TOP 10...

23. Case #2 - Single-sign on, multiple XSSes
• Major sports web page
• Set of web applications used for different purposes (subscriptions, estore, auctions, etc.)
• Payouts were offered only for high/critical vulnerabilities (SQLi, RCE, Persistent XSS)
• WAF in place for certain subdomains

24. That tricky registration mechanism
• Number of applications in scope of program allowed to create account in the application
• Account created in any of these web apps was valid for all the other applications in scope
• User e-mail address was published in each of these web applications – in most cases it was
encoded
• Filtering mechanism existed during registration, emails address needs to be provided in a valid
format
But what actually is a valid format for e-mail addresses?

25. What actually is a valid e-mail format?
• E-mail address format is defined in RFC 5321 and RFC 5322
• Better explained in Wikipedia
• This makes ”<script>alert(1)</script>”@gmail.com address completely fine from the RFC perspective
• Most of the web pages does not allow to register yourself with these addresses.... But some do 

26. Let the persistent XSSes begin!
• One of these web pages in scope allowed to register yourself with
”<script>alert(1)</script>”@gmail.com address, however it encoded malicious characters properly
• However, some other web page in scope did not allow funny e-mail addresses, but output
encoding mechanism was not there
• Remember that tricky registration mechanism?
• Most likely the only impacted person would be the account owner...
• ... but you never know - Persistent XSS in Profile Overview section (Bounty!) 
???
PROFIT!!!

27. Moar XSSes!!!
• Seems that certain well-known applications which are often integrated with web pages also allow
to use „quoted” e-mail addresses
• Application in scope supported PayPal payments and PayPal supported „quoted” e-mail addresses
Let me purchases that item
store.example.comUser
How do you want to pay?
PayPal.
And here is my PayPal account which is
”<script>alert(1)</script>”@gmail.com
OK, mail address seems valid,
I’m redirecting you to PayPal web page

28. Moar XSSes!!!
• Seems that certain well-known applications which are often integrated with web pages also allow
to use „quoted” e-mail addresses
• Application in scope supported PayPal payments and PayPal supported „quoted” e-mail addresses
paypal.comUser
I can see that you are
”<script>alert(1)</script>”@gmail.com
and you are coming from store.example.com.
Authenticate yourself to pay with PayPal.
Changed my mind, I’m cancelling the payment.
No worries, let me redirect you back to store.example.com

29. Noone expected the scope change!
• store.example.com has a full list of successful/unsuccessful transactions with details about
success/failure
• PayPal e-mail address used during transaction is presented in transaction details and is not
encoded
• Persistent XSSes which have no clear impact on other users were excluded from program scope 
???
NO PROFIT!!!

30. Case #2 - Summary
• 2 persistent XSS identified and 1 bounty received for simple vulnerability
• Excellent example why input filtering might not be enough to secure your web application
• It also seems that this company does not rely on pre-approved code snippets for e-mail
verification, as mechanism worked differently between applications

31. Case #3 – E-mails, e-mails everywhere
• It is more series of cases related to e-mail sending functionalities
• Web applications in scope? Pretty much everything – ecommerce, airlines, FMCG,
cybersecurity
• Thing in common? All of them were sending emails from the application to the end user

32. Case #3.1 – Me, myself and I
• Well-known international web page
• Couple of months without any vulnerability reported
• Just by knowing Bob’s temporary e-mail address i can spoof Alan’s messages.
• Bob’s temporary e-mail address is not visible in the web browser, but it is visible in JSON responses...
• I can negotiate prices and contract terms with myself, non-repudiation is being affected (Bounty!)
ecommerce.comBob
I want to Chat with Alan!
POST
Msg=Chat message:Hello World!
Alan
Message from: Bob
<gasr23basd1axne@
ecommerce.com>
Hello World!
Reply to: Bob
<gasr23basd1axne
@ecommerce.com>
Hello Bob!
Chat with Alan
Bob: Hello World!
Alan: Hello Bob!

33. Case #3.2 – Spidering does not work anymore
• Applications send multiple e-mails (newsletters, password reset, account activation, notifications)
• URLs (functionalities) which are embedded in these e-mails are often vulnerable to numerous
attacks
– „Unsubscribe” functionality – vulnerable to reflected XSS (Bounty!)
– IDOR in „Newsletter settings” functionality leads to unauthorized data modification (Duplicate)
– „Welcome” e-mail contains URLs with parameters never encountered before (Bounty!)
– Hyperlink included in e-mail vulnerable to IDOR and ultimately leads to account takeover
(Bounty!)
– Password reset e-mails contain URLs. User e-mail address is sent in GET parameters. Google
indexes these URLs and e-mail values (Bounty! X2)

34. Bug Bounty Hunter/Pentester – Quick wins
#1:
• Register an account in your application with ”<script>alert(1)</script>”@gmail.com
• Go to „My profile” section or equivalent
#2:
• Subscribe to all newsletters, notifications, promotions, gift cards.
• Create new account, forget password, restore password, unsubscribe, delete account.
• Check received e-mails for hyperlinks with fancy parameters. Look for XSSes, IDORs.

35. How to avoid these issues? - Basics
• During testing process analyze all the application interfaces and non-standard way of inputting data
• Make sure that Integration tests cover security aspects
• Use defense-in-depth principle
• Make sure that your TEST environment is as similar to PROD environment as possible and that scope
of your security tests include all of the system components and functionalities.

36. How to avoid these issues? - Advanced
• Ensure that you security testing team understands the business processes supported by the
application and has a good understanding of the entire tested ecosystem
• Regularly perform Google dorking to identify any cases of unintentional public access to sensitive
data or functions
• Analyze any cases of cross-system data dependencies. Implement cross-system segregation of duties
wherever possible.

37. Q&A Marcin Szydlowski
@securityksl