We live in a world where developers and security teams are drowning in
alerts. Every scanner, every automated tool, every “security dashboard”
promises to tell you what matters—but in reality, most of it is noise.
We live in a world where developers and security teams are drowning in
alerts. Every scanner, every automated tool, every “security dashboard”
promises to tell you what matters—but in reality, most of it is noise.
During my OSCE journey I came across an interesting technique to jump backwards
into the very beginning of the buffer injected on the vulnerable process.
The egghunting is a technique used in exploit writing to deal with evil
shellcode to be placed in a memory location different from the one we are
redirected via EIP overwrite or SEH hijack or other.
Sometime I need to quick nmap the network just right cable plug. Since I’m lazy
I created a simple bash script to calculate the network address in CIDR
notation, starting from ifconfig output.
During those days I’m spending in the mountains with my family, I’m studying module 3 and 4 about backdooring executable with custom payloads and avoiding anti-viruses based on signature detection.
Past weeks were busy for Ruby on Rails core team and appsec people looking at
the framework’s security. Yesterday, core rails member Aaron
Patterson announced three Ruby on Rails
security issues affecting latest versions and obviously all the web
applications out there built on affected issues.
Today I was working over a new tabular output for Codesake::Dawn and I faced a
problem. Vulnerabilities have a very long description that breaks all
formatting resulting in something unreadable.
It was a busy month. Web sites out there are still attacked by villains and the
first
Codesake::Dawn
major release was out this week. That’s because I didn’t post anything since
last December.
Wow, last week it was very busy in the ruby security annonuncement discussion
group. A bunch of
six new vulnerabilities were announced and, most of them, are cross site
scripting issues. This is bad for a problem floating around those places since
more than a decade.
UPDATE
For a mistake this post appeared today on
armoredcode.com without the text. Reason is that I
created a placeholder to remember me to work on this.
It finally happened. You discovered that your favourite online store website
has a REST API to suggest usernames. It’s a common pattern to allow the user
registration form to suggest alternatives username when the choosen one is
already taken. This feature is so user-friendly, so userful that almost
every project manager or sales representative will fight to have it online.
Tomorrow I’ll deliver a talk @SMAU, an Italian ICT… I
don’t know how to describe it… may be expo can be good. It’s not a technical
conference, well in Italy we don’t have a proper culture of having fun and
interesting technical conference. A decade ago it was a broaden event open to
customers and the main goal for visitors was to collect gadgets.
Yesterday a friend of mine asked about truly random number generation in Java
and which are my thoughts about Random and SecureRandom classes.
Of course I told him to use
ESAPI
calls since they are supposed to be robusts and well designed.
During 2013 a lot of websites were defaced. Attackers mostly use SQL injection
vulnerable pages to steal data, execute arbitrary commands or make some nasty
things common people can’t understand
A couple of days ago, I was starting a new security activity over a website I
never saw before. If you remember a last year
post,
the first task is to crawl the website looking for intersting pages.
A premise: I don’t trust gantt and fancy IT project managers’ document where
every project step fits in a perfect order without dealing with the
unpredictable.
In an ideal world, all projects has good management. Projects needs strong
decisions and a clear plan that make people able to build something; this is
true for a bridge, an house and even for software.
Web applications rely on server to bring users services. You read this blog and
you take care of your web application security very seriously. Maybe you have
also web application firewalls in front of it to face-off first time attackers.
It was a dark and stormy night back in 2006 when I started the
Owasp Orizon project
which I dedicated an ad hoc story on this blog back in
november 2012
Finally the day I gave the talk is arrived and it’s gone. Going on stage in
front a more than 450 talented developers was an astonishing experience. It
drove me crazy. My spoken English has limits on its own, but it in front of
such crowd I seemed to be a scared 4 years old child.
Julie Powell is an American writer who
creates a blog back in 2002. She wrote about an American woman lived in Paris
in 1949-or-something that innovates American cooking scenario writing a book
(in English) talking about novelle cousine.
With a colleague we were wondering about how much difficult is to create an
application security awareness climate in big corporate development team.
Please bear in mind that since I’m working in Italy my experience is very
narrowed to my country. If you have different stories to tell, please drop them
in this post comments area and share them.
Even before starting writing complex input filters to manage your users’ input,
you must care about the password you use on your servers.
If they are poor, no application security on Earth would save you against a break-in.
Some days ago, on a Facebook.com group about Italian startups, a smart guy said
he had a breakthrough product he is going to develop: a cloud based solution to
store people sensitive health-related information.
2013 is well promising for application security. Two days ago Aaron Patterson,
a rails core member announced a SQL Injection vulnerability for
ActiveRecord ORM included in Rails framework.
Two weeks ago, I posted an article
about a real world source code security review. Using regular expressions I was
able to spot interesting things over JSP files I was reviewing.
Client was happy.
My workflow was smooth.
Authentication is a cool topic in application security research nowadays. Last
April I posted about a real world security assessment activities over a friend
of mine PHP powered portal.
Next time you point your browser to a /login url wait a minute before
submitting your credentials. There is a complex system you’re going to use when
you submit that form and it must be honored in some way.
Make a web application penetration test is becoming tricky due modern browsers
native anti-xss filtering facilities (they only work for reflected cross site
scripting).
There were an annoying bug affecting the internal application security self
service platform I deployed on my company.
When a user makes a request the notification email is sent with an empty body.
Today I launched a first minimal website for
codesake.com. The website is very minimal and just a
subcribe to beta program web form it is present on the homepage.
Yesterday I was in a meeting for an appsec activity about a legacy PHP web
application. In front of my a couple of experienced developers with an in-deep
knowledge of their code and their architecture (and sometimes this is the good
news of the day).
Yesterday I was driving back home on my
scooter.
It’s a 40 minutes long trip and while surfing back and forth across crazy cars
not respecting speed limits I have got a lot of time to think.
Suppose you’re writing highlight something very important, and something
less important that it won’t to you to win the Turing award.
And after awhile, you write highlight another piece of text that you really want to highlight.
Life is too short to change framework or to learn a new programming language
only because there is no a shortcut to print out if a string starts with a
given pattern.
It’s one of my recurrent thoughts. Tools must expose an API allowing people to
customize the tool behaviour to fit their needs.
Nexpose it is a commercial tool for vulnerability
assessment exposing an API and I’m happy about it.
Bugs? They happen. No one on Earth is smart enough to write a 100% bug free
piece of code.
No matter how good are you, you’re users still will try use your forms in an
unpredictable ways making your app to miserably fail.
Since a week far away I’m on vacation at Guardavalle Marina, in the very
Southern of Italy. Here I’m relaxing trying to fixing up some tool I use as
application security specialist at work.
IT world do is a complex world. There are a lot of different people having
their own vision of the world, each of them with their own respectable opinion
about hot to write great software.
Session cookies are a swiss army knife for every developer to maintain user
session requests tracking. They need however to be designed with security in
mind since they can be used to claim an authenticated session by an attacker.
Today I attended the Italian RubyDay with a talk about application security.
More in details the talk was about how to use ruby
to automate some security tests as described in the Owasp Testing Guide.
Two days ago, the Internet was squashed by a very large sensitive data breach.
More than 6.4M of password hashes coming from
LinkedIN were published by an unknown attacker crew
exposing a large number of users to a credentials disclosure.
The work as application security specialit is to tell people how to improve
their app o their overall system configuration from the security point of view.
Ruby is a great language for hackers and security researchers too. Of course
you can build amazing web applications using Rails or
Sinatra or even Padrino
frameworks. You can also build great tools using sophisticated APIs that make
very easy to craft HTTP requests, to intercept traffic, to run regular
expression or even to build a transparent proxy in very few lines of code.
Did you ever think about how much information did you disclose when you publish a website?
In order to control how the site will appear in search results, webmasters
create a robots.txt
file telling crawlers what they have to consider in their indexing quest and
which urls they must ignore so search engines won’t show in search results.
The first time I started blogging on armoredcode.com
domain, it was 16th July 2010. They were strange days, without
energy and with lack of motivational spin.
Stay in the loop
Subscribe to get curated insights directly in your inbox.