The document discusses a talk focused on hacking and securing RESTful APIs, aimed at developers familiar with API structures and common vulnerabilities. It highlights various security flaws, particularly through the lens of the OWASP API Security Top 10, and explains techniques for testing API security by manipulating requests to identify weaknesses. Notable vulnerabilities include insecure direct object references (IDOR) and excessive data exposure, emphasizing the importance of understanding potential security risks in API responses.

2. About Me
• PhD in Cyber Security + Machine
Learning
• Security researcher
• Ethical hacker with a specialism
in Mobile APIs
• YouTuber and educator in web
and API security @InsiderPhD

3. About this talk
• Designed for developers
• I’m going to assume you are
familiar with RESTful APIs
• How to hack your own APIs to
test for security flaws
• Common API security flaws to
watch out for
• Tools you can use to test your
security

4. Hacking

5. The cycle
Try
exploit
Doesn't
work
Work out
why
Change
exploit

6. Interesting => Vulnerable
• Try to perform a test for the bug
I’m looking for
• IDOR = change ID
• XSS = simple XSS payload
• Did it work?
• Write a full exploit to show as a
PoC
• Did it fail?
• Why did it fail? Eg filtered
• Retest with a change
I’ve got a good feeling
about this XSS Watson

7. The Cycle
Try
exploit
Doesn't
work
Work out
why
Change
exploit
Exploit it

8. RESTful reminder
• RESTful APIs are really easy to spot
• They have a defined structure which relates
to CRUD functionality
• You can easy predict new endpoints simply by
knowing an application
• Eg: If YouTube’s API has something like GET
/video/1
• You can assume DELETE /video/1 also exists
• And that if YouTube has videos maybe GET
/comment/1 exists for comments
• They are widely used, however some of the
endpoints may be more custom
• Eg DELETE /posts/1 vs POST /posts/1/delete
• They usually return JSON

9. We need to see requests

10. Hacking is about fiddling with things
• We make small changes to a
request and see if that changes
the response
• Asking ourselves ‘what could an
attacker do this this?’
• The hard part is knowing what
change to make!
• For that info we need to look at
specific vulnerabilities

11. OWASP API Security top 10
• API1:2019 Broken Object Level Authorization
• API2:2019 Broken User Authentication
• API3:2019 Excessive Data Exposure
• API4:2019 Lack of Resources & Rate Limiting
• API5:2019 Broken Function Level
Authorization
• API6:2019 Mass Assignment
• API7:2019 Security Misconfiguration
• API8:2019 Injection
• API9:2019 Improper Assets Management
• API10:2019 Insufficient Logging & Monitoring

12. Excessive Data Exposure

13. What is it?
• When an API returns too much
information
• For example if you are booking a
hotel room, should the API be
returning the names of all other
guests at the hotel? Or just the
number of rooms
• Extreme example but this
happens
13

14. The recipe for an information disclosure
• Call the API
• Look at the response
• Is it disclosing too much info?
• Bonus points:
• Enumerating through the API to
find hidden endpoints
• Enumerating through the
parameters to find hidden
parameters
14

15. Clues
• For information disclosure we are
looking for an API that returns back
too much info
• Sometimes an API might return a
ton of info but never display it
• Or only display some of it
• Or has a lot of parameters –
suggests some querying is being
done that we can change
• These are clues that an API might
be vulnerable
15

16. Skills you need
• Keep an eye out
• Think about the security risk of what
information is returned
• Make a judgement call
• Is it a security risk?
• Could it be used to help a larger
attack?
• Does the target really want this
public?
• Does it return a large amount of data?
• Just because it’s working as intended
doesn’t mean that there are no
security risks
16

17. Broken Object Level Authorisation
Broken Function Level
Authorisation
AKA IDORs

18. What’s an IDOR?
• IDOR stands for Insecure Direct Object Reference
• Fancy term which means it doesn’t check if you can
actually access or modify something
• Example: your account is ID 4
• Delete account ID 4 – Should work, it’s your
account
• Delete account ID 3 – Shouldn’t work, it’s not your
account
• Another example: You are a guest
• View post ID 4 – Should work, you only have view
permissions
• Edit post ID 4 – Shouldn’t work, you don’t have
permission
18

19. The types of IDORs

20. Admin functionality

21. The recipe for an IDOR
• Find endpoints with IDs in the request
• Change the ID (to another account
you own – don’t test on accounts you
don’t own)
• If it works it’s an IDOR
• Find endpoints that require admin
permissions
• Login to an account that has guest
permissions
• Repeat the requests to the admin
endpoints, changing the cookies
• If it works it’s an IDOR
21

22. [IDOR] Deleting other people's tasks
22

23. IDOR bug to See hidden slowvote of any user even when you dont have
access right
23

24. Bypass of my three other reports #267636 + #255894 + #271861 - (IDOR) Ability to see full
name associated with other New Relic accounts
24

25. A story of a vuln

26. Impact, impact, impact
• Giggle Drama:
https://research.digitalinterrupti
on.com/2020/09/10/giggle-
laughable-security/
• Technically simple IDOR
• BUT
• Had consequences due to the
nature of some of the categories
on the app
• Eg partners fleeing abuse could
have been located