Can OWASP ZAP be performed on a protected website? - security

I am new to ZAP 2.5 and I have these questions that are yet answered as of the moment:
Can ZAP be performed in a protected website? Note that I don't know what method is used to protect the website. But whenever I try to perform ZAP with it, it only checks the Log In form of the website; ZAP doesn't dig deep down. Is it normal knowing that the website is protected?
I am not hacking the website; its just that my mentor wanted me to know if I or ZAP has the ability to perform security testing with our website even if it is protected. Is it really possible? If so, how?
I hope that someone would enlighten me with this, because so far, I haven't found any answers yet. Thank you!

It can. You can read read how to configure it in the manual.

Security tools like ZAP dont work by magic. They allow you to automate repetitive tasks that would take a manual pentester much longer to perform manually.
If you have a complex login process then you will need to understand how it works in order to configure ZAP how to handle it. Proxy your browser through ZAP. Login manually and look at the requests and responses that are proxied. Try to understand how the authentication works - once you have done that you can start looking at how to automate logging in via ZAP.

Related

How to prevent user from modifying REST request?

This question might sound trivial, but even after reading a number of tutorials, I still don't get how the REST security should be implemented.
I have a webpage and soon-to-be-ready mobile app. Both of them will be using the REST API (written in node.js), and the question is - how can I prevent users from modyfing those requests? It's very easy to see the network traffic in the browser, and all the GET/POST requests that are made to the server. It also seems very easy to copy such a request, modify its parameters and/or payload and send it to the server.
How do I make sure that's my webpage or the app who made the request, and not someone else?
Sisyphus is absolutely correct: your focus should be on securing the channel (TLS, SSH, etc) and authentication (e.g. OAuth2).
You should absolutely familiarize yourself with the Open Web Application Security Project (OWASP). In particular, start with:
OWASP Top 10 Cheat Sheet
OWASP REST Security Cheat Sheet
Here is an excellent "hands on" tutorial that gives you a great overview of all the different pieces you need to worry about:
Authenticate a Node.js API with JSON Web Tokens
Once you've gone through the tutorial and scanned the OWASP cheat sheets, you'll have a much better idea of what kinds of things you need to worry about, what options/technologies are available to mitigate those risks, and what might work best for your particular scenario.
Good luck!
Typically, security these days uses a combination of Transport Layer Security and OAuth2. OAuth2 provides authentication and authorisation, ensuring appropriate access to resources, with TLS both securing data over the network and preventing the kind of replay attacks which you're concerned about. Neither are really specific to Restful APIs and you can find them being used in non-Rest contexts also.

How to attack my own website?

I am currently working on security for a website (JSP) that contains 2 pages: a login and a data page. Once a user logs in, he is able to SELECT data from a specific table with read only access.
After browsing security risks online, I have wrote down a general list of what I might have to defend against
Injections
XSS
Auth / Session hijacking
CSRF
Direct Object Ref
Currently, I am reading about how to defend these attacks and what I should include in my code. However, I won't really know if my code actually works unless I test these attacks out for myself (and even then, there still might be other attacks that work). Right now, I just want some security, and thus I need to know how to produce these attacks so I can try them on my site.
Injections were simple as all I had to do what type '1'='1 in my code to reveal that it was flawed. Then I used prepared statements and SQL injections didn't work anymore.
How can I produce the rest of these attacks to see if my security atleast works against basic attacks?
(Also, is there perhaps some safe site or tool I can use to test out my vulnerabilities?)
I assume from your list that you're looking at the Open Web Application Security Project Top Ten. Good!
Really, the best advice I can give is to read through the OWASP site. A good first step would be to go through the individual links on that page (e.g. Broken Authentication and Session Management) and check the "Am I vulnerable?" section. Here are some further hints:
XSS
The XSS Cheat Sheet can be pretty helpful here. More examples than you can shake a stick at, ready to paste into your site.
CSRF
OWASP's wiki has a CSRF Testing Guide full of great links and suggestions.
Auth/Session hijacking
Well, are you using HTTPS? See this answer for more.
More resources
If you want to Go Deeper and do some real testing, here are some things you can do:
Read the Web Application Hacker's Handbook.
Try out some of the examples on http://hackthissite.org and the Google Gruyere project and see if you can break into them.
Download Kali Linux and learn to use some of the tools that come with it.
Go to a security conference or minicon near you and connect with other infosec people. Maybe I'll see you there :)

111-222-1933email#adress.tst hacker

I am learning website languages, and i am still a beginner. I am building a website that uses registrations, logins, adds, and so on... First I used PDO in my php in order to prevent mysql injections. Anyway I was hacked, they did not delete the database but it is full of this e-mail 111-222-1933email#adress.tst, and a strange code. I think that they used acunetix to see the leaks of mine website.
My question is: Do you know whats he hacker did, and what measures (besides PDO) can i use in my website to have a little bit more of security?
Use http://www.php.net/manual/en/pdo.prepare.php to create paramerterised queries - only use quote as a last resort.
As for your website, it could be anything - review all server and firewall logs as a starting point.
I am not an expert in php, but I think PDO by itself does not protect you from sequel injections when you take input from the user. you still have to use the PDO method quote to protect yourself.
http://php.net/manual/en/pdo.quote.php

Going Live - Any best practice check list and how to increase security on an MVC Site?

I have been building quite a few MVC based websites locally and am finally ready to deploy the first, but, I am getting rather nervous.
During testing, I noticed several things that worried me - I am using the default forms authentication with a few tweaks (although nothing to the underlining security).
I noticed that if I created a user in one application and logged in, then launched another application... it would keep me logged in* as the user from the previous application. The user doesn't even exist in the new application!
* - I used [Authorize] on controllers, and was surprised I could just get straight in without any sort of authentication
I assume it is because the cookie is being set for localhost instead of the application/port (although, not too much I can do about this in development).
Based on this, how secure is the default authentication?
1. Is there anyway to check from the code that the user doesn't have a "faked" cookie? / Check the user has logged in from my application?
2. I was just wondering if there are any sort of check lists or anything I can go through before deploying?
Sort of - 3.As of writing this, For question 1. I am guessing I could add a column with a random number that is saved to the cookie, and then that number is checked every time any authentication is done... however, I did not want to start mucking around with the membership provider... but I think this could work. Is this a good idea?
Try using IIS on your machine instead of VS Dev Server. Solves your problem 1.
Other than that I don't think you will need any extra effort to make default membership mechanisms of asp.net to make more secure if of course you don't need a real custom things to do in your projects. These things are around for a while now and I think they have been well tested in terms of security.
You just need to remember to put [Authorize] attribute to right places. If not on your controllers put them to right methods.
Basic Web Authentication shouldn't be trusted for applications which contain truly sensitive information. That being said it's sufficient for most applications. Be sure to check your application as often as possible before and after release for XSS vulnerabilities.
Here is Microsoft's recommended "Secure yourself" list. http://msdn.microsoft.com/en-us/library/ff649310.aspx
No matter how strong your authentication is, one small XSS mistake and a malicious user can do as they wish to your site, and your users data!
I recently read a good book: Worx Professional ASP.NET, it talks about these steps in more detail on securing yourself as well as exposing examples of problems. After reading this I was able to "deface and steal" my own sites information with relative ease, was a good eye opener on the importance of securing for XSS.

Ensure exclusive access to webservice

Just to be on the safe side, what's the best practice to ensure that only my application has access to my webservice, which is hosted on a public server? Should I implement I shared key or something?
My webservice is hosted on Googles App Engine and my Application runs on iPhones and iPads.
If you need further information, just ask.
Thanks,
Henrik
some sort of challenge/response authentication would be your best bet, but you could use something as simple as a key that's sent with every request. it might be quite easy for someone with a packet sniffer to reverse engineer that security though - i guess the amount of time you spend on it will relate to how much you really care :)
If you require your iphone app users to enter a loginid/password, then it is trivial to achieve what you want. But I assume you don't want that ..
Without that, there is no way to ensure you app has exclusive access to your web-services. People can always sniff HTTP traffic and spoof it. People can decompile/reverse-engineer your app to figure out the key/password.
See other discussions on StackOverflow - How to restrict access to my web service? and How can I create and use a web service in public but still restrict its use to only my app?
You could program your app to only serve requests that include your iPhone's unique identier - see StackOverflow question [Unique identifier for an iPhone app]. The id could still be sniffed, so depending on your needs, you may need methods to counter that.
Well, i had similar problem. What i realized, there is no 100% solution. What i did is, i used different approach. I have implemented OAuth and SSL, of course and than make algorithm for my web service to learn behavior of my app.
I try to put that algorithm in some kind of pattern, template, so it can be used in more scenarios. It's still in developing, so here is code of simple console app that will simulate that algorithm. Hope this can help:
https://github.com/vjeftovic/LearningRESTSimulation

Resources